The setting I missed that broke everything silently
1. Why markdown editors behave differently with the same syntax
I was testing the same note on Typora, Obsidian, and StackEdit. It looked fine in all three — until I actually tried copy-pasting the rendered content into Notion. Obsidian collapsed my nested list; StackEdit preserved it but stripped my inline tags; Typora added an invisible newline that broke a Zap trigger somewhere downstream.
The markdown spec is like HTML in the 2006 era: everyone pretends to follow the rules, but each tool does its own thing with just enough Wrangler-code underneath to keep it pretty — until you press Ctrl+C. And then suddenly it matters that you used a tab instead of spaces or wrote a bold line followed by a heading with no line break in between.
Key behavior differences I hit recently:
- Typora auto-closes tags in Smart Mode, even if you didn’t input both ends.
- Obsidian respects CommonMark but adds invisible frontmatter hooks that break exported Markdown.
- Notable uses recursive heading parsing, which sometimes eats h3s inside collapsed h2s.
- StackEdit uses GFM but includes MathJax — which explodes if you write a dollar sign followed by a number and indent a line somewhere below.
What looked synced across platforms wasn’t. The edge case that kicked off the chaos: I set up a Zap to parse H2 blocks in Markdown notes stored in Google Drive, but it triggered twice on one file because Typora left a stray Unicode character at the end of the heading. I didn’t see it until I opened it in VS Code with hex view on.
2. Auto-syncing markdown files creates silent overwrite loops fast
I naively thought I could write notes in Obsidian and sync them via Dropbox to my mobile editor of choice — IA Writer. Worked for three days until I accidentally re-opened a file on mobile that hadn’t pulled the newest changes. Closed the file. Didn’t touch anything. Three hours later, all my desktop edits were replaced by the older mobile version.
The sync looked correct. File timestamps were newer. But because Dropbox had locally cached the edit from IA Writer, and because IA Writer does a full overwrite save when you close a file, the last write killed everything.
No “merge” logic. The syncing layer treats Markdown as raw text. This means no awareness of what changed — only which file wrote last. You won’t notice a thing unless you habitually push to git, which I didn’t for that repo because the folder also had random lab scratchpads and I didn’t want noise in version control.
Fix: add a .gitignore for all files except your /content/ folder, and use VS Code GitLens to review diffs even if you’re syncing elsewhere.
This also saved me from a weird bug: changes saved in IA Writer were syncing via Dropbox, but didn’t update in Obsidian until I manually refreshed the vault. Didn’t realize for a full day I was editing a stale file.
3. How embedded links in markdown mess with block references
If you use anything like [[Note Title]] or ![[Image.png]] in daily notes, you’ll at some point hit the problem where copying content into another editor — Notion, Google Docs, your email client — results in a completely missing reference. Not a dead link. A full no-show.
What’s happening here is that Obsidian parses doublesquare links dynamically. The file isn’t altered — all you see in the source is the brackets. But external tools like Marktext or Typora don’t resolve that syntax, and depending on your export flow, that text may be replaced or ignored during export.
One thing that tripped me up: using Obsidian’s “Copy Obsidian URL” feature doesn’t mean you get Markdown. You get the internal URI format like obsidian://open?path=Some/Path which is useless in web tools or automation workflows. Unless your automation is on the same machine, and Obsidian is running, those links break or silently fail.
A better approach for linked structure: switch to relative directories (../ProjectA/note.md) and include a frontmatter field like alias: to make searching easier in other platforms. Not all Markdown renderers respect frontmatter, but at least it survives plain text migration.
4. Table formatting breaks Airtable imports if you use pipes wrong
So I thought I was being clever — wrote a bunch of feature comparison notes in markdown table format. Stuff like:
| App | Local Sync | Highlighting |
|----------|-------------|--------------|
| Obsidian | ✅ | ✅ |
| Typora | ✅ | ❌ |
Then I went to import it into Airtable. Used the CSV import block via clipboard paste. Forgot that markdown tables aren’t comma-separated. Airtable guesses column breaks by line format or comma spacing. Which means the cleanliness you see in your editor has zero impact on true structure.
Also turns out if you misalign a pipe, like:
| App | Sync | Highlighting |
| Obsidian | Yes | Yes |
| Typora | Yes | No |
…the Airtable import will sometimes swallow one cell entirely. No warning. No error. You just end up with a row that’s missing data. Found this buried in a bug thread from two years ago — still true.
What finally worked: use Typora to export as HTML, then use the browser to copy → paste the rendered table view into Google Sheets. Then clean up formatting and import that into Airtable via CSV export.
5. Unexpected whitespace turns into HTML tags during Markdown export
This took embarrassingly long to catch. I copy-pasted some notes in Obsidian that contained code blocks copied from VS Code. Pasted, edited, moved on. Exported via Pandoc to HTML because I needed to send a Wrike update to the team. Code sample sections were gone. Instead, the export had empty <pre> blocks.
Turns out VS Code adds non-breaking spaces as indentation when copying blocks with tabs. Obsidian renders these correctly. But Pandoc doesn’t parse non-breaking spaces as valid code block indicators. So your fenced code block:
console.log('hi');
…silently fails if that indent is instead of a normal space character. No warning. No output. You only catch it if you open the HTML and notice zero content inside the code block.
The fix is not bulletproof: open DevTools on your browser output and look for codes, or install a VS Code extension that literalizes whitespace during copy. I now copy to Sublime first — it auto-converts indentation to real spaces.
6. Hidden frontmatter fields confuse AI-powered summarizers
I started using Notion AI to auto-summarize meeting notes that I take manually in markdown inside an Obsidian vault. I tried piping those notes through GPT-4 initially, which worked better, but wanted faster previews on Notion mobile. So I set up a flow: write notes in markdown, drop into a synced folder, use Zapier to automate pushing content into Notion with a tag-based filter on the first line.
Problem: Obsidian auto-adds hidden YAML frontmatter if you generate a daily note with a template. Even if you never look at it. Summarization tools — especially Notion AI, but also many AI content miners — see frontmatter first and treat it as content. So if your frontmatter contains a field like:
tags: meeting, urgent, internal…you sometimes get a Notion summary like “Meeting to discuss tag urgent internal systems” — nonsense. The AI isn’t hallucinating. It’s just assuming that the first block of text is part of the discussion.
I now pre-strip frontmatter in the automation before pushing to Notion. Insert a Regex Remove Formatter in Zapier right before the Create Page step. Use:
^---\n[\s\S]+?\n---…to delete YAML headers. Annoying edge case? This step also removes any dashed list items at the very top. Found that out when a note with this line:
- Urgent: renew license before Monday…got removed because I typed it before the frontmatter finalized. The automation saw the heading and thought it was YAML.
7. How GPT interprets bold and bullet hierarchy when summarizing
When I started feeding meeting summaries into GPT-4, I assumed the bold headings and bullet nesting I wrote in Obsidian would help structure the answer. You know, like:
**Main Topic**
- Sub-point A
- Detail 1
- Detail 2
**Next Topic**
But GPT doesn’t actually respect markdown hierarchy unless it’s explicitly patterned — e.g. H2-H3 structure or numbered outlines. Bold doesn’t mean anything to it unless trained that way. And bullets? Only matter if you make it care using prompt context.
I got better results when I added a preamble like:
“Each ** section marks a topic; indentations mark sub-ideas.” Suddenly summaries were accurate.
Weird moment: one summary suddenly repeated the phase “Client review cycle confirmed by Jason” twice. Looked at the source. One was bold, one was regular. Both identical otherwise. The model weights bolded items slightly higher if they’re clustered near headings.
I now flatten all notes before summarizing unless hierarchy is clearly defined. Better yet, I preprocess them with a quick Python script that auto-numbers headings and folds bullet levels into `1.1`, `1.2`, etc.