Pull Structured Data Out of Documentation
You’ve got a feature comparison table in a Confluence wiki page. Or a list of API endpoints in a README. Or test cases formatted as a Markdown table in an Obsidian note. The data’s there, but it’s trapped in pipe-delimited text.
This tool parses Markdown table syntax into a JSON array of objects. Header row becomes keys, each data row becomes an object. It handles the separator row (the |---| line) correctly, trims whitespace from cells, and produces clean, indented JSON.
Example
| Name | Age | City |
|------|-----|----------|
| John | 30 | New York |
| Jane | 25 | London |Becomes:
[
{ "Name": "John", "Age": "30", "City": "New York" },
{ "Name": "Jane", "Age": "25", "City": "London" }
]All values come out as strings. If you need numbers as actual JSON numbers, post-process the output in your code with a quick parseInt() or parseFloat().
Where This Is Useful
Extracting data from READMEs. A library’s README has a table of supported options with columns for name, type, default, and description. You want that data programmatically. Paste the table, get JSON, and consume it in your tooling.
Obsidian and Notion workflows. You keep structured data in Markdown tables in your note-taking app. When you need to use that data in code, convert it here rather than reformatting by hand.
Test case management. Your test plan lives in a wiki as a Markdown table. Pull the test cases as JSON to feed into your test runner or CI pipeline.
Content migration. Moving from a Markdown-based CMS to a headless CMS that takes JSON? Convert the tables and import them.
The table needs to follow the standard Markdown format: pipes at the beginning and end of each row, a separator row with hyphens. Tables without leading/trailing pipes might not parse correctly.
The JSON to Markdown Table converter goes the other direction. Everything runs in your browser, and your data stays private.