Fast, practical, browser-based developer tools
Format, beautify, validate, minify, sort JSON keys, copy output, and download JSON instantly. This browser-based JSON formatter is useful for developers, API testers, backend teams, frontend engineers, and anyone working with structured JSON data.
Raw JSON can be hard to read when it comes as one long line or contains deeply nested objects. This tool helps you beautify JSON, validate structure, sort keys, minify output, and inspect it visually in a collapsible tree view without installing software.
This JSON formatter is designed to work directly in your browser during normal use. That makes it useful for quick formatting, validation, API testing, and local debugging workflows.
For more details about site usage and analytics, read our Privacy Policy.
Paste your JSON into the input area, then choose the action you need. You can format, validate, minify, or sort JSON keys, then inspect the result in the viewer and copy or download the output.
{
"name": "john",
"skills": ["json", "api"],
"active": true,
"profile": {
"country": "US",
"role": "developer"
}
}
A formatter looks like it only adds whitespace, but under the hood it does
JSON.parse() followed by JSON.stringify(), and that round trip
can silently rewrite your data. The parse step throws away anything that is not valid
JSON to begin with, and the stringify step normalises what survives. If the string that
comes out has to match the string that went in — a signature, a hash, a stored blob — you
need to know exactly what changed.
Numbers are the clearest example. JSON has one number type and no notion of an integer
versus a float, so the formatter re-serialises every number in canonical form.
1.0 becomes 1, 1e2 becomes 100,
.5 becomes 0.5, and trailing zeros disappear. The values are
numerically equal, but the text is not, and a byte-for-byte comparison will fail.
Webhook providers such as Stripe, GitHub, and Shopify sign the raw request body with an HMAC. The signature covers the exact bytes, whitespace included. The moment you run that body through a formatter — or your framework re-serialises it before you verify — the byte sequence changes and the signature no longer matches. This is why every webhook guide tells you to verify against the raw payload before parsing, never after pretty-printing it.
Sort Keys makes this worse, not better. JSON objects are unordered by
specification, but the text has an order, and reordering keys changes the bytes. There is
also a subtler trap: in JavaScript, object keys that look like non-negative integers are
always emitted in ascending numeric order regardless of insertion order, then the
remaining string keys follow in insertion order. So {"2":"b","1":"a","name":"x"}
comes back as {"1":"a","2":"b","name":"x"} from a plain format, before you
even ask it to sort. If you depend on key order, JSON is the wrong contract.
When JSON is produced from live JavaScript values rather than text, the losses are worse.
undefined, functions, and Symbol values are dropped from objects
entirely and become null inside arrays. NaN and
Infinity both serialise to null. A Date becomes an
ISO-8601 string and does not turn back into a Date on parse. A
BigInt throws a TypeError outright. None of this is a bug — it is
what JSON.stringify is defined to do — but it means a JSON document is a lossy
snapshot of the object it came from, not a faithful clone.
Duplicate keys are the one loss that happens purely in text. {"a":1,"a":2} is
valid JSON per RFC 8259, which only says keys should be unique. Parsers resolve
the conflict by keeping the last occurrence, so the formatted output shows a single
"a": 2 and the first value is gone with no warning. If a formatter ever
collapses two fields into one, that is why.
JavaScript parses every JSON number into an IEEE-754 double, which represents integers
exactly only up to 253 − 1, or 9007199254740991. A Twitter/X
status ID, a Discord snowflake, or a 64-bit database primary key is larger than that, so
the moment it is parsed it snaps to the nearest representable double and the last few
digits change. Format that JSON and you have now written the wrong number back out —
silently, with no error.
You cannot fix this in the browser after the fact, because the precision is already gone
by the time the string finishes parsing. The correct fix lives on the producing side: an
API that returns 64-bit IDs should send them as JSON strings ("id": "17298…"),
which is exactly what well-designed APIs do. If you must handle the numbers in JS, a
parser with a BigInt reviver keeps the value intact — but a plain formatter
will not.
JavaScript parses JSON numbers as IEEE-754 doubles, which hold integers exactly only
up to 253 − 1 (9007199254740991). Anything larger — snowflake
IDs, 64-bit primary keys — rounds to the nearest representable value on parse, so the
formatter writes back a slightly different number. The fix is on the API side: send
such values as JSON strings.
HMAC webhook signatures from providers like Stripe and GitHub cover the exact raw bytes of the request body, whitespace and all. Pretty-printing, minifying, or sorting keys changes those bytes, so verification fails. Always verify the signature against the untouched raw payload before you format or re-parse it.
Not the meaning — JSON objects are unordered by specification, so a consumer parsing by key gets the same result. But it changes the text, which matters for diffs, signatures, and hashes. Never sort arrays, though: arrays are ordered in JSON, and reordering their elements is a real change to the data.
Your input had duplicate keys, like {"a":1,"a":2}. RFC 8259 permits this
and parsers keep the last occurrence, so the formatter emits a single key and the
earlier value is discarded without warning. If a field vanished, check the original
for a repeated key.
Semantically no — both parse to the same values, since JSON ignores insignificant whitespace. Minifying only strips the spaces and line breaks between tokens to shrink transfer size. The one caveat is the round trip itself: both operations re-serialise numbers to canonical form and drop duplicate keys.
JavaScript object literals are not JSON. Trailing commas, single quotes, unquoted
keys, comments, and undefined are all legal in a .js file
and illegal in JSON. The parser reports the position just after the offending token,
so look one character before where it points.