Imagine spending years building a personal knowledge base, only to lose access because an app shuts down or changes its pricing. It happens more often than you'd think. Markdown eliminates that risk entirely.
So what is a markdown file, exactly? It's a plain text document that uses simple symbols to represent formatting — hash marks for headings, asterisks for bold and italics, dashes for lists. Created in 2004 by John Gruber, Markdown (sometimes searched as markdown语法) is a lightweight markup language designed so your documents stay readable as raw text while also converting cleanly into HTML. No proprietary database. No vendor lock-in. Just portable, structured files you can open with any text editor on any operating system.
For note-taking specifically, this matters because your notes are long-lived. A .md file written a decade ago still opens perfectly today. Proprietary formats come and go, but plain text outlasts every app on the market.
Markdown's portability means your notes survive any app migration. You will outlive the companies behind today's note-taking platforms — your format should too.
Most markdown language cheat sheet resources dump syntax tables without context. They tell you how to write a heading but not when to use one in your notes. This markdown guide cheat sheet takes a different approach. Every syntax element is paired with a practical note-taking use case, and the article progresses from basics through advanced extensions into real workflows.
Think of it as a markup cheat sheet that doubles as a system-building guide. You'll start with essential formatting, move into block-level elements and app-specific extensions, then finish with ready-to-use templates and organizational strategies. The goal isn't just memorizing syntax — it's turning that syntax into a markdown cheatsheet you actually apply every day when capturing and retrieving knowledge.
Structured notes start with a handful of core formatting elements. You don't need to memorize dozens of symbols — six or seven patterns cover the vast majority of everyday note-taking. The trick is knowing which element fits which situation, so the syntax becomes muscle memory rather than something you look up every time.
Headings give your notes a scannable hierarchy. In Markdown, you create them by placing one or more hash signs (#) before a phrase. One hash produces the largest heading (H1), two hashes give you H2, and so on down to H6. The Markdown Guide recommends always placing a space between the hash signs and the heading text for compatibility across processors.
For most notes, H1 serves as the document title, H2 marks major sections (like agenda topics in a meeting note), and H3 handles sub-points within those sections. Going deeper than H3 is rarely necessary unless you're writing long-form documentation.
Text emphasis works the same way across nearly every Markdown app. Wrap a word or phrase in single asterisks or underscores for italics markdown styling (*text* or _text_), and double asterisks or underscores for bold (**text**). You'll use bold to flag key decisions or deadlines, and italics in markdown to add subtle emphasis — book titles, terminology, or side notes that shouldn't dominate the line.
A common question is how to handle underline in markdown. Markdown doesn't include native underline syntax because underlined text on the web typically signals a hyperlink. If you genuinely need underlined text, you can use the HTML <ins> tag, but most note-takers find bold or italics sufficient for emphasis.
Lists are where Markdown really shines for note-taking. A markdown bullet list starts each line with a dash, asterisk, or plus sign followed by a space. These are perfect for brainstorming, capturing action items, or jotting down quick observations without worrying about order.
When sequence matters — steps in a process, ranked priorities, or agenda items — switch to a markdown numbered list. Start each line with a number and a period (1., 2., 3.). A useful detail: the actual numbers you type don't need to be sequential. Markdown renderers auto-number the list based on order, so you can use 1. for every item if you prefer easy reordering.
Line breaks and separators round out the basics. To create a markdown newline within the same paragraph, end a line with two trailing spaces before pressing return. For a visual divider between distinct topics — say, separating morning notes from afternoon notes — insert a markdown horizontal line using three dashes (---), asterisks (***), or underscores (___) on their own line.
The table below pulls all of these elements together in one copy-ready reference, pairing each syntax pattern with a practical note-taking scenario.
| Element | Markdown Syntax | Rendered Result | Note-Taking Use Case |
|---|---|---|---|
| Heading 1 | # Title | Title (largest) | Document title or note name |
| Heading 2 | ## Section | Section (large) | Meeting agenda topics, major sections |
| Heading 3 | ### Sub-section | Sub-section (medium) | Sub-points under a main topic |
| Bold | text | text | Key decisions, deadlines, important terms |
| Italics | text | text | Book titles, subtle emphasis, side notes |
| Bullet list | - item | • item | Action items, brainstorm ideas, observations |
| Numbered list | 1. item | 1. item | Step-by-step processes, ranked priorities |
| Line break | Two trailing spaces + return | New line within paragraph | Separating short lines without a full paragraph gap |
| Horizontal rule | --- | Solid divider line | Separating topics, dividing AM/PM notes |
With these nine elements alone, you can capture meeting notes, outline projects, and organize daily logs. They form the backbone of any markdown syntax cheat sheet — and once they feel automatic, you're ready to layer in richer block-level elements that turn flat text into a true knowledge document.
Headings, lists, and emphasis handle the skeleton of a note. But some ideas need more than a bullet point — a key insight from a book, a code snippet you want to preserve exactly, or a comparison that only makes sense in rows and columns. That's where block-level elements come in. They give your notes depth without sacrificing the simplicity of plain text.
When you encounter a sentence worth remembering — a quote from a colleague, a passage from an article, or a principle you want to revisit — the markdown quote syntax captures it cleanly. Place a > character at the start of a line, and the text renders as an indented, visually distinct block.
Single-line usage is straightforward:
> The best time to organize your notes is before you need them.
For multi-paragraph markdown quotes, add a > on the blank line between paragraphs. You can also nest quotes using >>, which is useful when you're annotating someone else's words with your own commentary — a common pattern in reading notes and research logs.
A well-placed block quote turns a wall of text into a scannable note. Use it for anything you might highlight in a physical book.
The quote markdown pattern also works inside lists, letting you embed a key takeaway directly beneath an action item or discussion point. This markdown quotation technique keeps attributed ideas visually separated from your own thoughts, so you always know what came from a source and what's your interpretation. The Markdown Guide recommends placing blank lines before and after block quotes for maximum compatibility across processors.
If you take notes that involve commands, configuration files, or code, you need a way to preserve formatting exactly as written. A markdown code block does this by preventing the renderer from interpreting any special characters inside it.
For short inline references — a function name or terminal command — wrap the text in single backticks: git status. This keeps the code visually distinct within a sentence.
For multi-line snippets, use a fenced code block. Place three backticks (`````) before and after the snippet. Add a language hint after the opening fence when you want syntax highlighting:
bash
git status
git commit -m "Update meeting notes"
 
The language hint, such as bash, python, or json, tells compatible Markdown renderers how to color the code. If you omit it, the block still preserves spacing and special characters, but syntax highlighting may not appear.
Indented code blocks are another option: indent each line with four spaces. They work in basic Markdown, but fenced code blocks are clearer, easier to copy, and better supported by note-taking apps.
Markdown tables are useful when your notes need structure beyond bullet points. They work well for comparing tools, summarizing meeting decisions, tracking study concepts, or organizing research sources.
A basic table in markdown uses pipes for columns and a separator row beneath the header:
| Topic | Detail | Status |
| :--- | :--- | :---: |
| Meeting notes | Capture decisions and action items | Active |
| Reading notes | Save quotes and summaries | Draft |
| Project ideas | Track next steps | Review |
Colons in the separator row control alignment: :--- aligns left, :---: centers text, and ---: aligns right.
| Element | Syntax | Best Use | |||
|---|---|---|---|---|---|
| Block quote | > quoted text | Capturing citations, insights, and key takeaways | |||
| Inline code | git status | Short commands, function names, and technical terms | |||
| Fenced code block | ````language` | Multi-line snippets with preserved formatting | |||
| Table | ` | Column | Column | ` | Comparisons, status tracking, and structured summaries |
Block quotes, code blocks, and tables turn Markdown notes into durable knowledge documents. Quotes preserve context, code blocks protect exact syntax, and tables make related information scannable at a glance.
Standard Markdown covers formatting. But real note-taking demands more — tracking tasks, citing sources, linking ideas together, and tagging notes for retrieval. These capabilities come from extended syntax features that various Markdown flavors have introduced over the years. Generic cheat sheets rarely cover them, yet they're exactly what separates a formatted document from a functional knowledge system.
Meeting notes without action items are just transcripts. The checklist markdown extension solves this by adding interactive checkboxes directly inside your notes. The syntax is minimal: a dash, a space, then brackets containing either a space (incomplete) or an x (complete).
• - [ ] creates an unchecked task (open item)
• - [x] creates a checked task (completed item)
In practice, a quick action list looks like this:
- [x] Draft project proposal- [ ] Send proposal to stakeholders- [ ] Schedule follow-up meeting
You can nest task lists under headings or mix them with regular bullet points. This makes them ideal for meeting notes where some items are informational and others require follow-up. Many apps that support GitHub Flavored Markdown render these as clickable checkboxes, letting you toggle completion without editing the raw text.
Beyond task tracking, several extensions turn isolated notes into an interconnected system. Here are the ones most relevant to note-takers:
• Callout/admonition blocks — Highlight a markdown warning, tip, or important detail using a special blockquote syntax. GitHub's format uses > [!WARNING], > [!TIP], or > [!NOTE] on the first line of a blockquote. Other apps like Obsidian use a similar pattern. These draw the eye to critical information without disrupting the flow of your notes.
• Footnotes — When you need a markdown citation or source reference without cluttering the main text, footnote symbols let you annotate inline and define the reference elsewhere. The syntax uses a caret inside brackets: [^1] in the body, then [^1]: Source details here at the bottom. Identifiers can be numbers or descriptive words — [^research-paper] works just as well. This is the cleanest way to markdown cite a source while keeping your prose readable.
• Wiki-style internal links — Connect notes to each other using double-bracket markdown link syntax: [[Note Title]]. This creates a bidirectional link between documents, forming a personal knowledge graph. Apps like Obsidian and Logseq rely heavily on this pattern for networked thinking.
• YAML frontmatter — Add structured metadata to any note by placing a block of key-value pairs between triple dashes (---) at the very top of the file. Common fields include title, tags, date, and status. YAML frontmatter enables powerful filtering and search across large note collections without altering the visible content of the note itself.
A practical example combining footnotes and frontmatter in a reading note might look like this:
---title: Deep Work Summarytags: [productivity, focus]---Cal Newport argues that deep work is becoming rare and valuable.[^1]
[^1]: Newport, C. (2016). Deep Work. Grand Central Publishing.
One important caveat: not every app supports every extension. Task lists are nearly universal, but footnotes, callouts, wiki-links, and frontmatter vary significantly across Markdown flavors and tools. Knowing which features your chosen app actually renders — and which it silently ignores — saves real frustration when you're building a note system you plan to rely on long-term.
That caveat about app support isn't a minor footnote — it's the single biggest source of confusion for people building a Markdown note system. You write a perfectly valid footnote or callout, switch tools, and the syntax renders as raw text. The reason? Not all apps speak the same dialect of Markdown. Understanding the major flavors helps you pick syntax that actually works in your environment.
John Gruber's original 2004 specification was intentionally loose, leaving common formatting cases undefined. As platforms needed features like tables and syntax-highlighted code blocks, each implemented them independently. The result is a family of dialects that share a core but diverge on extended features. Three flavors matter most for note-takers:
• CommonMark — A strict, unambiguous specification published in 2014 to resolve the original spec's edge cases. It covers headings, emphasis, lists, links, images, code blocks, and block quotes. It does not include tables, task lists, or footnotes. Think of it as the reliable baseline every markdown format cheat sheet starts with.
• GitHub Flavored Markdown (GFM) — Built as a formal extension of CommonMark, GFM adds tables, task lists, strikethrough, and autolinks. If you've ever wondered about the GFM meaning in documentation contexts, it refers specifically to this superset that GitHub standardized in 2017. Most note-taking apps borrow heavily from GFM's feature set.
• MultiMarkdown — Extends the original spec with footnotes, definition lists, math support, and metadata. A multimarkdown cheat sheet would include citation syntax and cross-references that academic writers rely on. Fewer mainstream apps implement it fully, but its footnote syntax has been widely adopted independently.
Each note-taking tool picks and chooses from these flavors, often adding proprietary extensions like wiki-links or callouts. No single markdown syntax cheat sheet can guarantee universal compatibility — but the table below shows exactly what works where.
This markdown formatting cheat sheet comparison covers the features discussed throughout this article. A checkmark means the app renders the syntax natively without plugins or workarounds.
| Feature | AFFiNE Pagedoc | Obsidian | Notion | Bear | Logseq | Typora |
|---|---|---|---|---|---|---|
| Headings (H1-H6) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Bold / Italic | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Task lists | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Tables | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Code blocks | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Block quotes | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Links | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Separators | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Footnotes | ✗ | ✓ | ✗ | ✓ | ✓ | ✓ |
| Wiki-links | ✗ | ✓ | ✗ | ✓ | ✓ | ✗ |
| Callouts | ✗ | ✓ | ✓ | ✗ | ✓ | ✗ |
| YAML frontmatter | ✗ | ✓ | ✗ | ✓ | ✓ | ✓ |
A few patterns stand out. AFFiNE Pagedoc natively supports headings, block quotes, checklists, tables, code blocks, links, and separators — covering the core Markdown syntax note-takers rely on most. It turns familiar Markdown formatting into structured, visual documents without sacrificing the simplicity of plain-text input, making it a strong workspace for anyone who wants clean notes without wrestling with raw files. Obsidian leads on extended features like footnotes, wiki-links, and callouts, making it the power-user choice for networked knowledge bases. Notion supports the visual result of Markdown input but stores content in its own database format, so portability is limited. Logseq pairs wiki-links with an outliner structure that appeals to non-linear thinkers.
The practical takeaway: if your notes rely primarily on headings, lists, quotes, tables, and code blocks, nearly every modern app has you covered. The divergence happens at the edges — footnotes, callouts, and metadata. Choose your tool based on which extensions you actually use, and keep your core formatting within the universally supported GFM subset so your notes remain portable regardless of where they live.
Knowing syntax is one thing. Seeing how multiple elements combine into a functional note is another. The templates below are designed to be pasted directly into your preferred app and adapted to your workflow. Each one demonstrates headings, lists, checkboxes, block quotes, and separators working together — the kind of real-world examples for syntax in action that most md cheat sheet resources skip entirely.
Meetings generate decisions, context, and follow-ups. A good template captures all three without slowing you down during the conversation. Here's a markdown code snippet you can copy into any compatible editor:
# Weekly Sync — [Topic]
## Details
Date: 2025-05-20
Attendees: @Alice, @Bob, @Carol
Location: Virtual
## Agenda
1. Review last week's action items
2. Project status updates
3. Blockers and decisions needed
## Discussion Notes
### Status Updates
Alice: Completed onboarding flow redesign
Bob: API migration at 70%, blocked on auth service
Decision: Delay auth migration to next sprint to unblock frontend work.
Bob — File ticket for auth service dependency
Carol — Share updated timeline with stakeholders
Alice — Finalize onboarding mockups (done)
## Next Meeting
Date: 2025-05-27
Focus: Sprint planning
Why is this template structured the way it is? Each design choice maps to a specific note-taking need:
H1 for the title — Keeps the note identifiable when scanning a file list or search results. Including the topic in the title means you never open the wrong meeting note.
H2 for major sections — Agenda, Discussion, and Action Items each get their own heading so you can jump between them quickly. Most apps generate a table of contents from H2 headings automatically.
Horizontal rules as dividers — The --- separators create visual breathing room between metadata, content, and follow-ups without adding extra headings.
Block quote for decisions — Wrapping key decisions in a > block makes them scannable weeks later when you need to recall what was agreed upon.
Task list for action items — Checkboxes let you track completion directly inside the note. Assigning names inline keeps accountability clear.
This structure draws on patterns used by experienced Obsidian users who build meeting templates with metadata, attendees, and Dataview-powered recent meeting links. You can simplify or extend it depending on how formal your meetings are.
Meetings aren't the only note type that benefits from a repeatable structure. Project tracking and reading notes each have distinct rhythms — one evolves over weeks, the other captures insight in a single session.
Project Note Template
# Project: [Name]
## Overview
Status: In Progress
Owner: @YourName
Start Date: 2025-04-01
Target Completion: 2025-06-15
Migrate user database to new schema
Reduce API response time below 200ms
Ship updated dashboard to beta users
Schema migration script tested in staging
Run migration on production (scheduled May 22)
Update API endpoints to use new schema
Draft migration plan reviewed by team
Backup strategy documented
## Resources
How do we handle rollback if row counts mismatch?
Do we need a maintenance window or can we migrate live?
Numbered goals at the top — A project note should answer "what are we trying to achieve?" within the first few lines. Numbered lists signal priority order.
Reverse-chronological progress log — The most recent week sits at the top so you see current status immediately. Each week uses H3 to stay nested under the Progress Log H2.
Checkboxes inside the log — Mixing completed and open tasks within each week gives you a running record of what shipped and what carried over.
Separate sections for resources and questions — Links and unresolved questions tend to get buried in running notes. Giving them dedicated headings makes them findable when you need them most.
Reading/Study Note Template
# Reading: [Book or Article Title]
## Metadata
Author: [Name]
Source: [URL or publication]
Date Read: 2025-05-18
Tags: #productivity #focus #deep-work
## Summary
One-paragraph overview of the core argument or thesis.
## Key Takeaways
> "Deep work is the ability to focus without distraction on a cognitively demanding task."
Shallow work expands to fill available time if not constrained
Time-blocking is more effective than to-do lists for deep focus
Ritualize the start of deep work sessions to reduce activation energy
How does this relate to [[Atomic Habits]] cue-routine-reward loop?
Could I apply the shutdown ritual to my end-of-day notes?
Block 2 hours each morning for deep work this week
Create a shutdown checklist template
Metadata block with tags — Frontmatter-style metadata (even without YAML delimiters) makes the note searchable by author, date, or topic. Tags using # syntax work in apps that support inline tagging.
Block quote for direct quotations — Preserving the author's exact words in a > block distinguishes their ideas from your interpretation. This is the markdown highlight technique for source material.
Questions and Connections section — This is where reading notes become part of a larger knowledge system. Wiki-links ([[Note Title]]) connect the current note to related ideas, building a web over time.
Application section with tasks — Reading without action is entertainment. Ending with concrete checkboxes turns passive consumption into behavior change.
All three templates use the same markdown syntax cheatsheet elements — headings, lists, checkboxes, block quotes, horizontal rules, and links — combined in patterns that match how you actually think during each activity. Save them as code md files in your note-taking app's template folder, and you'll never start from a blank page again. The real power emerges when you pair these structures with consistent organizational habits — folder conventions, naming patterns, and linking strategies that make retrieval as effortless as capture.
Templates give you a strong starting point for individual notes. But a collection of well-formatted files still becomes chaotic without a system holding them together. The real payoff of consistent Markdown formatting isn't how a single note looks — it's how easily you can find, connect, and reuse information across hundreds of notes over months and years.
Every markdown note you create needs a home that's predictable enough to navigate without thinking. The goal is a folder hierarchy that's shallow enough to browse quickly but descriptive enough to separate distinct areas of your life or work.
A structure that scales well for most people uses two to three levels at most:
notes/
work/
projects/
meetings/
personal/
journal/
finance/
learning/
books/
courses/
reference/
templates/
cheat-sheets/
Top-level folders represent life areas. Second-level folders represent categories. Resist the urge to pre-create deeply nested trees — add subfolders only when a directory holds more than five files. This keeps navigation fast whether you're browsing in a file manager or using markdown tabulation in a terminal.
Naming conventions matter just as much as folder placement. Recommended practices for filenames:
• Use lowercase with hyphens instead of spaces — sprint-retro-notes.md avoids issues in URLs and CLI tools
• Prefix chronological notes with ISO dates — 2025-05-20-team-standup.md sorts naturally
• Use descriptive names for reference notes — api-auth-patterns.md beats notes.md
• Keep a readme file (index.md) in key folders to serve as a local table of contents
These conventions turn your file list into a scannable index. When every note follows the same pattern, you can locate what you need through filename search alone — before you even open a file.
Folders handle physical location. Links and tags handle meaning. Together, they cover the full note-taking lifecycle: capture, structure, link, retrieve.
Here's how consistent Markdown formatting supports each stage:
• Capture — Use a daily note or inbox file as your default landing spot. Jot ideas quickly using markdown lists and checkboxes. Don't worry about placement yet.
• Structure — During a weekly review, move captured items into dedicated notes. Apply heading hierarchies (H1 for title, H2 for sections, H3 for sub-topics) so every note is scannable. Use horizontal rules (---) to separate distinct topics within a single document.
• Link — Connect related notes using wiki-links ([[Note Title]]) or standard Markdown links. A knowledge base with 8,000 notes and 64,000 internal links demonstrates that dense connections — averaging around 8 links per note — make retrieval dramatically easier than relying on folders alone.
• Retrieve — YAML frontmatter tags (tags: [project-alpha, backend]) let you filter notes across folders. Consistent headings act as anchors for full-text search — when every meeting note uses ## Action Items, a single search query surfaces every open task across your entire vault.
One often-overlooked technique: use a comment in markdown (<!-- hidden note -->) to embed search-friendly metadata or reminders that won't render in the final output. This is the same HTML comment syntax you'd use in any .html file. It's handy for leaving yourself processing instructions — like <!-- TODO: merge with project-beta notes --> — without cluttering the visible content. You can also use a markdown tab character (a four-space or actual tab indent) to nest content inside markdown lists for additional hierarchy within a single bullet point.
The underlying principle is simple: formatting isn't decoration. Every heading, tag, and link you add is a retrieval hook your future self will use. A system built on these habits — shallow folders, consistent names, dense links, and searchable metadata — turns a pile of markdown comments and scattered files into a knowledge base that gets more useful the larger it grows. The remaining question is which workspace best supports these habits without adding friction to the process.
Your syntax knowledge and organizational habits are only as effective as the environment you practice them in. The right workspace removes friction between thinking and writing — it renders your Markdown cleanly, supports the features you rely on, and stays out of the way while you build your knowledge system.
Not every editor deserves a spot in your workflow. When evaluating options, weigh these criteria against how you actually take notes day to day:
• Live preview or hybrid rendering — Can you see formatted output as you type, or do you toggle between raw text and a separate preview pane? Inline rendering reduces context-switching and keeps you in flow.
• Syntax support breadth — Does the app handle the elements you use most: headings, block quotes, checklists, tables, code blocks, and separators? Check the compatibility table from earlier in this article rather than trusting marketing pages.
• Export and portability — Can you export to standard formats like PDF, HTML, or plain .md files? If you ever want a markdown cheat sheet pdf for offline reference, your workspace should produce one without third-party converters.
• Collaboration features — Do you share notes with teammates or work solo? Real-time editing and commenting matter for team knowledge bases but add complexity for individual use.
• Knowledge management integration — Does the tool support linking, tagging, or structured views that help you retrieve notes months later? A workspace that only formats text without helping you organize it solves half the problem.
Sites like quickref.me offer handy ref sheet lookups for syntax reminders, but they can't replace a workspace that renders your notes visually and connects them into a system. You need both: a quick reference for the occasional syntax check, and a daily environment where formatting happens naturally.
AFFiNE Pagedoc hits a practical sweet spot here. It renders core Markdown syntax — headings, block quotes, checklists, tables, code blocks, links, and separators — into clean, structured documents without requiring you to manage raw files or install plugins. The result is a workspace that bridges raw Markdown writing and visual knowledge organization, letting you build organized notes without leaving a single environment. For anyone who wants the portability mindset of Markdown combined with the clarity of a polished document, Pagedoc is worth exploring.
You now have everything this md cheatsheet covers: foundational formatting, block-level elements, note-taking extensions, flavor compatibility, copy-ready templates, and organizational workflows. That's more than most markup cheatsheet resources offer — and more importantly, it's structured around how you actually use notes rather than how a spec document defines syntax.
The next step is small but decisive: pick one template from this article, paste it into your workspace, and take your next set of notes with it. Syntax becomes automatic only through repetition. Bookmark this page as your standing reference — a cheat sheets collection you return to whenever a less common pattern slips from memory — and let consistent practice turn knowledge of Markdown into a system that compounds over time.
The most effective meeting note structure uses H1 for the meeting title, H2 for major sections like Agenda, Discussion, and Action Items, and task list checkboxes (- [ ] and - [x]) for tracking follow-ups. Block quotes work well for highlighting key decisions. This combination lets you capture context, decisions, and next steps in a single scannable document that any Markdown-compatible app can render.
Headings, bold, italics, bullet lists, numbered lists, block quotes, code blocks, tables, links, and horizontal separators are universally supported across major note-taking tools including AFFiNE Pagedoc, Obsidian, Notion, Bear, Logseq, and Typora. Extended features like footnotes, wiki-links, callouts, and YAML frontmatter vary by app. Sticking to the GitHub Flavored Markdown subset ensures maximum portability if you ever switch tools.
Use a dash followed by a space and square brackets: '- [ ]' creates an unchecked task, and '- [x]' creates a completed task. These render as interactive checkboxes in most modern note-taking apps that support GitHub Flavored Markdown. You can nest them under headings or mix them with regular bullet points to separate informational items from actionable follow-ups within the same note.
CommonMark is the strict baseline specification covering headings, emphasis, lists, links, and code blocks. GitHub Flavored Markdown (GFM) extends CommonMark with tables, task lists, strikethrough, and autolinks. MultiMarkdown adds footnotes, definition lists, math support, and metadata aimed at academic writing. Most note-taking apps borrow from GFM for everyday features and selectively adopt MultiMarkdown's footnote syntax for citation needs.
Use a shallow folder hierarchy with two to three levels representing life areas and categories. Name files with lowercase hyphens and prefix chronological notes with ISO dates for natural sorting. Beyond folders, connect notes using wiki-links or standard Markdown links, apply tags through YAML frontmatter for cross-folder filtering, and maintain consistent heading structures so full-text search reliably surfaces relevant content. Tools like AFFiNE Pagedoc help by rendering this structure visually within a single workspace.