Markdown to JSON Converter: How to Use It Step by Step

How do you convert Markdown to JSON?

You paste your Markdown into the Markdown to JSON Converter, pick either Markdown AST or Notion blocks, and the tool returns a JSON tree you can copy or download as document.json. All parsing happens in your browser.

The reason to bother: Markdown is a flat string. Headings, list nesting, and code fences only become structure when a parser interprets them. LLM output, README files, and note exports are all Markdown, so any pipeline that needs to chunk, filter, or re-render that content must first answer a simple question — which part is a heading, and which paragraphs belong under it?

The converter answers that in one paste. The Markdown to JSON Converter re-renders the JSON on every keystroke (debounced), and a footer shows node counts so you can confirm the parse produced roughly the shape you expected before you wire it into anything.

Step-by-step: paste, pick a format, copy

Step one is pasting. Drop your Markdown into the monospace textarea, or click the Load sample link first if you want to see the expected shape. The badge above the field reports the character and line count, which is a quick sanity check that the whole document arrived — for a dedicated count of a specific field later, a character counter is more precise than eyeballing the badge.

Step two is choosing output. The selector next to the textarea switches between Markdown AST and Notion blocks. You can change it after pasting; the JSON re-renders immediately, so there is no Run button and no re-paste.

Step three is the pretty-print toggle. On gives 2-space indentation that reads well in a diff or a code review; off gives minified single-line JSON that is smaller when you are pasting into a request body. Then hit Copy for the clipboard, or Download .json — the file is saved as document.json for AST output and notion-blocks.json for Notion blocks, generated client-side with a Blob URL.

AST or Notion blocks: which should you pick?

Pick Markdown AST when your own code will consume the tree; pick Notion blocks when the payload is going straight to the Notion API.

The AST is a generic tree in which each node carries a type and, where relevant, children. A heading node holds inline children for its text and emphasis, and a list node has one child per item. That is the vocabulary most Markdown tooling already speaks, which makes it the right choice for custom renderers, chunking pipelines, and token accounting.

Notion blocks swap in Notion's own vocabulary — heading_1, paragraph, bulleted_list_item — with text wrapped in rich_text arrays and annotations, so the array can go into a page-creation request body. Check field names against the Notion API block reference before shipping, because Notion adds required fields over time.

Neither mode rewrites your prose. Text is preserved as-is, including inline HTML, so treat the output as a structural view of the document rather than a normalization pass.

What happens to GFM edge cases?

The parser accepts GitHub Flavored Markdown: headings, nested and ordered lists, tables, blockquotes, fenced code blocks with their language tag kept as info, task list items, inline HTML, and YAML frontmatter. The GitHub Flavored Markdown specification is the reference for how each construct should be interpreted.

The most common self-inflicted failure is an unterminated code fence. If you paste three backticks and never close them, everything below is absorbed into one code node — the node-count footer is how you notice. Mixed tabs and spaces cause a subtler problem, because GFM treats a tab as four spaces of indentation, which can change how deeply a list item nests.

Frontmatter is worth a deliberate decision. Note apps and static site generators often emit YAML frontmatter at the top, and it will appear as its own node in the JSON. If your consumer only wants body content, filter it out rather than assuming it was stripped.

Pasting rendered HTML instead of Markdown is the other frequent mistake. The converter reads Markdown syntax, so a copied web page gives you one big paragraph node rather than a document tree.

Wiring the JSON into RAG, agents, and CMS imports

For retrieval pipelines, chunk by node rather than by character count. Walk the top-level array, carry a heading path such as H1 > H2 > H3 as chunk metadata, and emit one chunk per paragraph or list block. Code blocks with their language tag make strong standalone chunks because they rarely need surrounding prose to be useful.

For agent prompts, the tree lets you point a model at specific nodes instead of asking it to re-parse a wall of Markdown. Passing only the children of one heading keeps the context tight and makes the model's answers easier to trace back to a source section.

For CMS importers, expect to write a small mapping from node types to your own schema. The converter hands you the tree, not a database-specific shape. The same is true for Notion: block types map cleanly, but page parents, properties, and database fields are yours to fill in.

Privacy, limits, and what to verify

Nothing is uploaded. Conversion runs in client-side JavaScript, so your document never leaves the tab, which matters when the input is an internal README or an exported meeting note. There is no account, no quota, and no rate limit, and the page keeps working offline once loaded. It sits alongside other browser-only utilities on OnlineFree.app.

The honest limitation is size. Because the parse reruns on each debounced keystroke, a very large Markdown file converts fine but is unpleasant to edit live in the textarea. The tool also does not validate your target schema — if your renderer expects different node names, you need a mapping layer between the output and your code.

Verification is about correctness, not privacy. Spot-check the first few nodes against the source, confirm the node count matches your expectation, and check platform-specific fields against the official docs before pushing anything to production. Treat the JSON as a structural draft you review, not a guaranteed round-trip.

References

• GitHub Flavored Markdown specification
• Notion API block reference