JSON to Markdown Table Converter
Turn JSON records into GFM tables while keeping nested field choices visible.
Arrays of objects are the clearest table source, but single objects, primitive arrays, and object-value collections are also supported.
Shape the rows first
Presentation choices
A table needs a row model before it needs Markdown
The hardest part of JSON-to-table conversion is not drawing pipes. It is deciding what counts as one row and which fields deserve columns. An array maps naturally to rows. A single object can be one row. An object whose values are records can instead use each value as a row while keeping the original member name in a collision-safe source-key column.
Auto detection only treats an object as a record collection when all of its values are objects. That avoids turning an ordinary settings object containing arrays or mixed primitive values into a surprising set of rows.
Flattened paths must not confuse a dotted key with nesting
A naive flattener can map both {"a.b":1} and {"a":{"b":1}} to the same a.b column. Here, simple member names use dot paths while names containing dots, brackets, quotes, commas, or other ambiguous characters use quoted bracket notation. Empty nested objects are retained as {} text instead of disappearing during flattening.
GFM tables require the delimiter row
GitHub Flavored Markdown defines tables as an extension with a header row followed by a delimiter row made from hyphens and optional alignment colons. A pipe-separated header without that delimiter is not a GFM table, so the generated Markdown always includes it. Literal pipe characters inside cells are escaped by default because an unescaped pipe separates cells in the table syntax. GitHub Flavored Markdown table specification
Pipe escaping protects table boundaries; it is not a general Markdown sanitizer. Values containing links, images, raw HTML, or other Markdown syntax can still be interpreted by the destination renderer. Treat untrusted content according to that renderer's security rules before publishing it.
Missing and null are not the same value
A field can be absent from one row while another row explicitly contains JSON null. The missing-field setting only controls absent fields. Explicit null remains the text null so that absence is not silently conflated with a value the source deliberately supplied.
Human-readable headings are presentation, not identity
Humanizing can turn names such as created_at into “Created At”, but two different source columns can humanize to the same visible label. The underlying column paths remain unchanged, and the page flags duplicate displayed headings so you can disable humanizing when exact field identity matters.
Valid JSON can still be unsafe to round-trip through JavaScript numbers
Duplicate object member names and precision-sensitive numeric tokens are rejected before table conversion. Otherwise JavaScript parsing could collapse one duplicate member or round a number before it reaches the cell formatter. RFC 8259 recommends unique member names and describes the interoperability range commonly available for JSON numbers. RFC 8259
When a Markdown table is the wrong destination
Tables work best for a modest number of rows and columns with short scalar values. Very wide records, deeply nested documents, long prose fields, or thousands of rows are usually clearer as JSON, a downloadable data file, or a purpose-built data viewer. The row-limit and width cautions are readability heuristics, not Markdown validity rules.
Browser limits
Input is capped at 2,000,000 characters, 20,000 derived rows, and 100 nested levels. Preview rendering is deliberately smaller than the generated output so one large paste does not create an enormous DOM table.