What indentation should I use for each format?

JSON and JSON5 have no required indentation — 2 spaces is the most common convention, 4 is popular in .NET and Python projects. YAML requires spaces (never tabs) and 2 spaces per level is the de facto standard. XML is whitespace-tolerant, so pick 2 or 4 for readability. TOML is line-based: keys sit flat under table headers, so indentation is purely cosmetic.

Why does my JSON fail to validate?

The most common causes are trailing commas, single-quoted strings, unquoted keys, comments, smart quotes pasted from a document, and Python-style True/False/None. Strict JSON allows none of these. Use Repair to rewrite them into valid JSON automatically.

How are XML attributes represented in JSON?

Elements become objects, repeated elements become arrays, and attributes become keys prefixed with @ — so becomes { "@id": "bk101" }. When an element has no child elements, its text content becomes the value directly.

Is my data uploaded anywhere?

No. Every operation — detection, validation, formatting, minifying, repairing and converting — runs locally in your browser. Nothing is sent to a server, so it is safe to paste API responses and config files.

{ }

Markup Mojo — JSON, XML & YAML Formatter

Beautify, validate & convert JSON, XML & YAML in your browser

Input

FromTo

Indent

Output

Formatted output will appear here.

Guide: formatting and converting JSON, XML, YAML, TOML and JSON5

A practical reference for the five data formats Markup Mojo supports: what each one is good at, the indentation and syntax rules that actually matter, what happens when you convert between them, and how to fix the errors you hit most often. Everything described here runs entirely in your browser — nothing leaves your machine.

The formats at a glance

Format	Extension	Typically used for	Key constraint
JSON	.json	APIs, config, data interchange	Strict: double quotes, no comments, no trailing commas.
JSON5	.json5	Human-edited config	JSON plus comments, unquoted keys, single quotes, hex, Infinity/NaN.
XML	.xml	Documents, SOAP, feeds, sitemaps	Attributes, namespaces and mixed content have no direct JSON twin.
YAML	.yaml / .yml	CI pipelines, Kubernetes, app config	Indentation is syntax. Spaces only — tabs are illegal.
TOML	.toml	Rust, Python (pyproject), tooling config	Line-based tables; unambiguous types including dates.

How to format any document

Paste your text into the left panel. The format is detected automatically.
Override the detected format with the From dropdown if needed, and choose a To format if you want a conversion rather than a reformat.
Click Validate to check the document, or Format to produce indented, syntax-coloured output with line numbers.
Use Minify to strip whitespace for transport, or Repair to rewrite broken JSON/JSON5 into something parseable.

Indentation rules per format

Only two of the five formats have real constraints. Everything else is convention, and conventions still matter because they keep diffs small in shared repositories.

YAML — 2 spaces, no tabs. Indentation is structural: it defines nesting. The YAML spec forbids tab characters for indentation, so Markup Mojo locks YAML output to 2 spaces.
TOML — not applicable. Keys belong to the most recent table header, so nesting is expressed by [table.subtable] rather than indentation. Canonical output is flat.
JSON / JSON5 — 2 or 4 spaces (or a tab). Purely cosmetic; pick one and stay consistent with your codebase formatter.
XML — 2 or 4 spaces. Whitespace between elements is insignificant, but be careful: whitespace inside a text node is part of the value.

JSON and JSON5

JSON is deliberately minimal: objects, arrays, strings, numbers, true, false and null. There are no comments, no trailing commas, no single quotes, and keys must be double-quoted strings. That strictness is why it is the default for APIs — but it makes hand-edited config files painful.

JSON5 relaxes exactly those points while staying a superset of JSON, which makes it a good fit for files humans maintain:

{
  // comments are allowed
  unquotedKey: 'single quotes too',
  hex: 0xFF,
  trailing: [1, 2, 3,],
  weirdNumbers: [Infinity, NaN],
}

Anything valid as JSON is valid as JSON5, so converting JSON to JSON5 is lossless. Converting JSON5 to JSON drops comments and rewrites keys, quotes and non-finite numbers — note that Infinity, NaN and undefined have no JSON equivalent at all.

XML

XML carries structure that flat data formats do not model: attributes, namespaces, comments, processing instructions, CDATA and mixed content (text and elements interleaved in the same node). Validation here means two different things — being well-formed (tags balanced and correctly nested) and being valid (matching a DTD or XML Schema). Markup Mojo checks well-formedness.

<catalog>
  <book id="bk101">
    <title>XML Developer's Guide</title>
    <price currency="USD">44.95</price>
  </book>
</catalog>

Watch for the five predefined entities — <, >, &, " and '. A bare & in text content is the single most common reason an otherwise fine document fails to parse.

YAML

YAML is a superset of JSON aimed at human authors: indentation instead of braces, - for list items, # for comments, and support for anchors and multi-document files separated by ---.

service: api
replicas: 3
env:
  - name: LOG_LEVEL
    value: debug
command: >
  run --port 8080

Three habits prevent most YAML bugs: never indent with tabs; quote values that could be read as another type ("yes", "no", "on", "1.0", version strings, leading-zero identifiers); and remember that a document with duplicate keys is invalid even though many parsers silently keep the last one.

TOML

TOML targets configuration that must be obvious to read and unambiguous to parse. It has first-class dates and times, explicit integer and float types, and table headers instead of nesting by indentation.

title = "Markup Mojo"

[owner]
name = "Ada"
joined = 1979-05-27

[[servers]]
host = "alpha"
port = 8080

The trade-off is deep nesting: a heavily nested JSON tree becomes long dotted table headers in TOML, which is why TOML suits settings files rather than arbitrary API payloads.

Converting between formats

All conversions go through a common in-memory model: the source is parsed into plain values, then serialised into the target format. That means conversion is only as faithful as the overlap between the two type systems. The practical caveats:

XML to JSON/YAML: elements become objects, repeated elements become arrays, and attributes become @-prefixed keys. Comments, namespace declarations and mixed content are not preserved.
JSON/YAML to XML: XML needs a single root element, so a top-level array is wrapped. Keys must be valid element names — keys with spaces or leading digits have to be renamed.
YAML to JSON: comments, anchors and aliases are resolved away, and dates become strings.
Anything to TOML: null has no representation in TOML, and arrays of objects become [[array-of-tables]] blocks.
Round-tripping: comments never survive a round trip through JSON. Keep the annotated file as the source of truth and treat the converted output as a build artefact.

Common errors and how to fix them

Message	Usual cause and fix
Unexpected token } in JSON	A trailing comma before the closing brace or bracket. Remove it, or run Repair.
Expected property name or '}'	Unquoted key, or a single-quoted string. Switch the format to JSON5 or repair to strict JSON.
Unexpected non-whitespace character after JSON	Two documents concatenated (often NDJSON). Repair wraps newline-delimited objects into an array.
bad indentation of a mapping entry (YAML)	A tab character, or a nested key indented inconsistently. Re-indent with 2 spaces.
Unexpected close tag / mismatched tag (XML)	An unclosed element or a typo in the closing tag; also check for a raw & in text.
Invalid or unexpected token (TOML)	An unquoted string value, or a key defined twice in the same table.

Frequently asked questions

What indentation should I use for each format?: JSON and JSON5 have no required indentation — 2 spaces is the most common convention, 4 is popular in .NET and Python projects. YAML requires spaces (never tabs) and 2 spaces per level is the de facto standard. XML is whitespace-tolerant, so pick 2 or 4 for readability. TOML is line-based: keys sit flat under table headers, so indentation is purely cosmetic.
Why does my JSON fail to validate?: The most common causes are trailing commas, single-quoted strings, unquoted keys, comments, smart quotes pasted from a document, and Python-style True/False/None. Strict JSON allows none of these. Use Repair to rewrite them into valid JSON automatically.
How are XML attributes represented in JSON?: Elements become objects, repeated elements become arrays, and attributes become keys prefixed with @ — so <book id="bk101"> becomes { "@id": "bk101" }. When an element has no child elements, its text content becomes the value directly.
Is my data uploaded anywhere?: No. Every operation — detection, validation, formatting, minifying, repairing and converting — runs locally in your browser. Nothing is sent to a server, so it is safe to paste API responses and config files.