DanfioSearch tools/

Type a tool name, a pinyin spelling or a synonym - both languages are searched.

JSON Formatter & Validator

Global tools

A JSON document is easy to read until it is one line of four thousand characters. This page lays it out, minifies it back down, sorts keys so two versions can be compared, and counts what is in it - and it does the thing that matters most when something is wrong: it says exactly where.

JSON Formatter & Validator - Danfio

https://danfio.com/tools/json-formatter/ - printed from this page

Strict JSON, the kind JSON.parse accepts: double-quoted strings, no comments, no trailing commas. The four mistakes that cause almost every error come with their own hint below.

Only whitespace changes: two spaces is what most style guides and code reviews assume, a tab is what older editors show, and minifying keeps the document valid while removing every optional space.

Sorting is for reading and for comparing two documents; arrays keep their order either way, because their order is data.

Leave it blank for "formatted.json".

Results update as you type. Nothing leaves your device.

Valid JSON - an object

15 lines

Indented with 2 spaces. Nothing was rewritten: the output parses back to the same value.

Input
164 B
Output
196 B
Keys
8
Levels deep
4

Formatted JSON

{
  "name": "danfio",
  "tools": [
    {
      "slug": "json-formatter",
      "stars": 4
    },
    {
      "slug": "base64-encoder",
      "stars": 3
    }
  ],
  "free": true,
  "notes": null
}

Copy it, or download it as a file. Formatting changes only the whitespace; sorting changes only the order of keys inside objects.

What the numbers do not say

  • 3 objects, 1 array, 3 strings, 2 numbers, 1 boolean and 1 null.
  • JSON has no integer type: a number is a double, so an identifier longer than about fifteen digits (a tweet id, a database key) can lose precision before this page ever sees it. That is the format rather than this tool - keep values like that as strings.
  • Duplicate keys inside one object are not an error in JSON: the last one wins, and the earlier ones are already gone by the time anything can count them.
The text was read, formatted and counted in this browser tab. There is no request behind the page, which is why pasting a token, a private config or a customer response here is no different from pasting it into a text editor.

The parsing is your browser’s own `JSON.parse`, the same parser that will read the file in production, so there is no "it worked here but not there": if this page calls a document valid, the strictest parser will agree. Nothing is uploaded, and nothing is rewritten apart from whitespace.

About this json formatter & validator

Within a stack trace, an API response or a config file, JSON stops being readable the moment it is one long line. This page lays it out, minifies it back down, sorts keys so two versions can be compared, counts what is in it, and names the exact line and column when something is wrong.

The check uses the browser’s own `JSON.parse`, the same rules production will use, so a document this page accepts is accepted by the strictest reader there is. There is no account and no backend: the text is validated and rewritten in the tab, and nothing is stored. Counts come from the values themselves, not the text.

Formatting changes whitespace and sortable key order and nothing else, and the output always reads back to the same values. Duplicate keys are quietly collapsed to the last one, which is the format failing softly. This page reformats and validates; it does not repair JSON for you.

How this json formatter & validator works

Strict JSON, and the four mistakes that cause almost every error

JSON has one set of rules and no extensions. Every string is double-quoted, every key is a string, there are no comments, no trailing commas, and no NaN, Infinity or undefined - those are JavaScript values, and the format has no way to write them. A JavaScript object literal that happens to look like JSON is usually not JSON: that is the single most common reason a config file will not parse.

So when the text is refused, this page names the mistake rather than only reporting it. A comma before a closing bracket gets "JSON does not allow a comma after the last item"; a single-quoted string gets "JSON strings use double quotes"; a bare key gets "JSON object keys must be strings"; and a `//` or `/* */` comment is called out as a comment. Those four, plus a missing value after a colon, account for almost every broken document anybody has ever pasted.

One thing strict JSON does *not* complain about is a duplicate key inside the same object. The last one wins and the earlier ones are silently gone - by the time anything can count them they are already gone from the parsed value. That is the format, and it catches people out because it fails quietly rather than loudly.

What formatting and minifying actually change

Formatting changes whitespace and nothing else: the indentation between tokens, which indentation, and whether there is any at all. Minifying is the same operation with the indentation set to nothing, so a minified document is not "compressed" - it is the same bytes of data with the spaces removed. The tests prove the point by parsing the output and comparing it with the value that went in: if formatting changed anything else, that comparison would fail.

Sorting is the one option that changes the text in a way you can see, and it only touches the order of keys inside objects. Arrays keep the order they arrived in, always, because an array is a sequence and its order is data - sorting one would be a bug rather than a feature.

That combination is what makes two documents comparable: format both, sort keys on both, and a line-by-line comparison of the two results shows real differences rather than the accidental order in which a serializer happened to write keys.

Where the numbers come from, and the two things JSON cannot carry

The headline counts are measured from the parsed value rather than from the text: objects, arrays, strings, numbers, booleans, nulls, how deep the document nests, and how many keys there are altogether. Bytes are counted in UTF-8, which is why a document full of emoji has more bytes than characters.

JSON has no integer type - every number is held at the browser’s fixed precision - so an identifier with more than about fifteen digits can lose precision the moment it is parsed, and that happens in every program that reads JSON, not only here. A tweet id, a database key or a bank account number belongs in a string for exactly this reason. The same goes for money, incidentally: `0.1 + 0.2` is a famous example of why a currency amount should travel as a string or an integer of minor units.

The other thing JSON cannot carry is a comment. There is no way to write one, which is why every configuration format that needs comments (JSON5, JSONC, YAML, TOML) exists - and why this page will not quietly strip them for you: a formatter that accepts almost-JSON lets almost-JSON into files that will be read by something strict.

Worked examples

Each example below was run through the calculator on this page when the site was built, so the numbers match what you see when you enter the same inputs.

An API response, made readable

How to lay it out: 2 spaces (the usual choice)

Valid JSON - an object

15 lines

Indented with 2 spaces. Nothing was rewritten: the output parses back to the same value.

Input: 164 B · Output: 196 B · Keys: 8 · Levels deep: 4

Two spaces is the convention nearly every style guide settles on, and it is the setting that keeps a document readable without making it enormous. The output parses back to exactly the same value that went in.

The same document, minified for shipping

How to lay it out: Nothing at all - minify onto one line

Valid JSON - an object

124 characters, one line

Minified: the whitespace between tokens is gone and the values are untouched.

Input: 164 B · Output: 124 B · Keys: 8 · Levels deep: 4

Minifying removes the whitespace between tokens and nothing else - the strings inside the document keep every space they had. A minified file is smaller to send and harder to read, which is why nobody reviews one.

Two versions of a config file, put in a comparable order

How to lay it out: 2 spaces (the usual choice) · Object keys: Sort keys A to Z, at every level

Valid JSON - an object

15 lines

Indented with 2 spaces, with keys sorted A to Z. Nothing was rewritten: the output parses back to the same value.

Input: 164 B · Output: 196 B · Keys: 8 · Levels deep: 4

Sorting keys at every level is what makes a diff usable: differences that matter stand out instead of being buried in a different key order. Arrays are never reordered, because their order is data.

Frequently asked questions

Is my JSON uploaded anywhere?

No. The text is read by JavaScript in this tab, parsed by the browser’s own `JSON.parse`, and formatted there; the download is created locally as a blob. There is no request behind the page at all - which is why pasting an access token, a private configuration or a customer response here is no different from pasting it into a text editor. APIs, credentials and personal data are exactly what people paste into a formatter, and that is exactly why this one does not have a server.

Why does it reject my config file that has comments in it?

Because the file is JSON5 or JSONC rather than JSON: comments are a superset several tools accept, and the format does not. Accepting them here would be the dangerous choice - the file would pass this page and then fail in whatever reads it in production. Either strip the comments at the source, or use the other format’s own tooling; the error message names the comment so you know it is not something subtler.

What does minifying actually remove?

The whitespace between tokens: indentation, line breaks and the spaces around colons and commas. It cannot touch the inside of a string, so a message with spaces in it keeps every one of them - whitespace inside quotes is data. Minifying typically saves 20-40% of a pretty-printed document and changes nothing about its meaning.

Why is my large number different after formatting?

Because JSON numbers use the browser’s fixed number precision, which holds about fifteen significant digits exactly. A sixteen or seventeen digit identifier can come back rounded, and that happens in every program that reads JSON, including the one in your backend. The fix is at the source: send identifiers, and money, as strings.

Can it sort the contents of arrays too?

No, and neither will anything else that respects the format: an array is a sequence, so its order carries meaning - a list of steps, a set of coordinates, the results of a query. What can be sorted is the keys inside objects, which exist for lookup rather than for order, and that is exactly what the option does at every level.

Where did my duplicate keys go?

The reader kept the last one, as every program that reads JSON does. Two identical keys inside one object are not an error in the format, so nothing complains; the earlier value is simply not there any more. If a document is built by merging objects, that is the mechanism that eats a value, and the only way to see it is to compare the input with the parsed output.

Can I compare two documents with this?

Indirectly: format both with keys sorted, and then a normal text comparison shows the real differences rather than accidental key order. A built-in diff is not part of this page, and a JSON-aware diff (one that understands moved subtrees rather than lines) is a genuinely different tool, so the copy stays honest about which one this is.

Does it validate against a JSON Schema?

No: it checks syntax, which is the question "is this JSON at all", rather than shape, which is the question "is this the JSON I expected". Schema validation needs the schema, and it reports a completely different class of problem (a missing required field, an unexpected type, a string that should be a number). Doing that badly would be worse than not doing it.

Assumptions and sources

  • The format is JSON as defined by RFC 8259 and ECMA-404: double-quoted keys and strings, no comments and no trailing commas.
  • Only strict JSON is accepted, so a document that almost parses is reported with its line and a hint instead of being quietly repaired.
  • Numbers keep your browser's precision (about 15 significant digits); the document never leaves the tab and is not uploaded.

Last reviewed 2026-09-16. Runs locally on your device; keep backups; no financial advice applies. Read the full disclaimer.

Where a figure on this page comes from an official agency — HUD, IRS, FICO or a state body — the site keeps a dated snapshot of the source page in its sources library, and a scheduled job re-checks that snapshot, so the number can be traced back to the document it came from.

Related tools

JSON to CSV ConverterDeveloper ToolsTurn a JSON array into a CSV table, or a CSV table into JSON, in your browser. Quotes, other delimiters, ragged rows and formulas handled. Nothing uploaded.Convert JSON to CSV →Base64 Encoder & DecoderDeveloper ToolsEncode text to base64 or decode it back, in your browser, with the standard and URL-safe alphabets, UTF-8 handled properly, percent-encoding and data URLs too.Encode or decode Base64 →JWT Decoder & Hash GeneratorDeveloper ToolsDecode a JSON Web Token and see what every claim means, check an HS256 signature against a secret, and hash text with SHA-256, SHA-1 or MD5 in the browser.Decode a JWT →Regex Tester & ReplacerDeveloper ToolsTest a JavaScript regular expression against your own text: every match with its groups and positions, what each flag does, and how it runs in Python or PCRE.Test a regex →Color ConverterDeveloper ToolsConvert between hex, rgb() and hsl() in your browser: paste one color, get all three formats and an sRGB channel preview.Convert hex, rgb and hsl →Cron Expression GeneratorDeveloper ToolsTurn a cron expression into plain English and the next run times: five fields or six, Vixie or Quartz, in any time zone, with the traps named. No upload.Build a cron expression →