{ } JSON Formatter
TextSorter JSON Formatter is a free online developer utility that allows you to beautify, minify, validate, and fix JSON instantly
Why Format, Minify and Validate Never Disagree About What's Broken
One parser, three jobs. Format, Minify and Validate all hand your text to the same strict JSON parser built into your browser first, so anything that fails for one of them fails for all three. They only differ in what happens once the parse succeeds.
{"a":1,"b":[2,3]}{
"a": 1,
"b": [
2,
3
]
}| Button | What it does once your text parses |
|---|---|
| Format | Rewrites the parsed value with two-space indentation and one line break per element. The style is fixed, there is no option to choose a different width or bracket style. |
| Minify | Rewrites the same parsed value with no whitespace at all, collapsing everything onto a single line. |
| Validate | Leaves your text exactly as typed and reports success, or the parser's exact error message, including the character position where parsing broke down. |
All three enforce identical rules with zero flexibility, because they all lean on the same strict implementation: property names and string values need double quotes, never single quotes; a trailing comma after the last item in an object or array is a hard failure, not a style choice; and there is no support for comments in any form. That is the JSON specification working exactly as designed, not this tool being unusually picky.
The gap that trips people up is the one between JSON and a JavaScript object literal. Code like {name: 'Alice', tags: ['a', 'b'],} runs fine inside a script, since JavaScript allows unquoted keys, single quotes and a trailing comma. None of that is valid JSON. Paste it here and Format, Minify and Validate all reject it the same way, because valid JavaScript syntax and valid JSON turn out to be related but not identical languages.
Same parser as your browser's console. The error message Validate shows you is the literal message a JSON.parse() call would throw inside your own application code, not a paraphrased version. If you have ever debugged a parsing error in a browser console, you already know how to read the ones this tool shows.
Why "Valid JSON" Can Still Be the Wrong Data
Validate checks grammar, not meaning. It confirms your brackets, quotes and commas are all in the right places. It has no idea whether a required field is missing or a number arrived as a string.
{"a": 1 "b": 2}Expected ',' or '}' after property value in JSON at position 8 (line 1 column 9)That message points at the exact character where the parser gave up: right after the 1, where it expected a comma or a closing brace and instead found the start of another property. Counting to that position in a text editor, or using its "go to character" command, is usually faster than reading through the whole payload looking for a missing comma by eye.
What Validate cannot tell you is whether the data is correct once it parses. A response can be syntactically perfect JSON and still be missing a field your code expects, hold a number as the string "42" instead of the number 42, or store the same date in three different formats across three different records. None of that is a grammar problem, so none of it produces an error here.
| Validate catches | Validate has no opinion on |
|---|---|
| A missing or mismatched bracket or brace | A required field that is simply absent |
| A missing comma between two properties | A string sitting where a number was expected |
| An unquoted or single-quoted key | The same field formatted differently across records |
| A trailing comma or a code comment | Data that is internally inconsistent but individually valid |
Syntax and meaning are two separate checks. This tool only performs the first one. For the second, a schema validator or your application's own type checking is the right tool, since judging what a value should mean requires knowing what your specific data is supposed to look like.
Why the Fix Button Breaks on Apostrophes Inside String Values
Fix cannot tell an apostrophe from a quote mark. It replaces every single quote in your text with a double quote, so a contraction like "it's" sitting inside a string value gets its apostrophe read as a closing quote, which usually breaks the very JSON it was trying to repair.
{name: "Alice", active: true, nickname: undefined,}{
"name": "Alice",
"active": true,
"nickname": null
}Behind that result is a fixed sequence of four find-and-replace passes, run in this order every time, whether or not your text actually needs each one:
| Step | What it rewrites |
|---|---|
| 1 | Every ' becomes a ", everywhere in the text. |
| 2 | A comma sitting right before a closing } or ] is deleted. |
| 3 | A bare word followed by a colon, like name:, gets wrapped in double quotes, but only if it starts with a letter or an underscore. |
| 4 | The literal word undefined becomes null. |
Step one is a blind global replace, not a parser that understands where a string starts and ends, and that is exactly what makes apostrophes dangerous. Feed it {'name': 'It's a test'} and step one turns every single quote into a double quote with no exceptions, producing {"name": "It"s a test"}. The apostrophe inside "It's" is now a quote character that closes the string two characters early, leaving a stray s a test" that no longer belongs to anything.
The repair usually fails outright rather than silently corrupting your data. That stray leftover text almost always breaks parsing a second time, so Fix reports "Could not auto fix this JSON" and leaves your editor content untouched, rather than handing back JSON with a quietly mangled string. The real cost is your time, not your data: you still have to quote that value by hand, because one blind find-and-replace has no way to distinguish an apostrophe from a delimiter.
Fix is also narrowly scoped by design. It cannot insert a comma that is missing between two properties, cannot strip a code comment, cannot convert an array closed with the wrong bracket type, and cannot notice or resolve a duplicate key, since none of those problems match any of its four regular expressions. If Fix fails, Validate's exact error position is usually the faster path to a manual repair.
Fix does nothing to text that already parses. Click it on JSON that is already valid and it shows an "already valid" message and leaves your text exactly as it was, formatting included. Click Format instead if you want valid JSON reformatted.
What Happens When Your JSON Has the Same Key Twice
The last occurrence quietly wins. The JSON specification does not forbid a repeated key, and this tool's parser resolves one by keeping only the value from whichever copy appears last, with no error and no warning.
{"name": "Alice", "name": "Bob"}{
"name": "Bob"
}Click Validate on that input and it reports valid JSON, which is technically correct: the specification only says implementations "should" treat names as unique, leaving the actual behavior up to whatever does the parsing. This tool's parser, the same one built into the browser, keeps the last value it sees for a repeated key and silently drops every earlier one. "Alice" is gone the moment parsing finishes, with nothing in the output to show it was ever there.
Format and Minify inherit the same behavior, since both parse your text before rewriting it. Run either on JSON with a duplicate key and the extra copy has already vanished by the time you see the result. That is easy to miss when the duplicate was accidental, a mistake made while merging two JSON snippets by hand, for instance, rather than something you meant to write.
Tree view is the fastest way to spot one. Since a duplicate key collapses into a single entry before it ever reaches the tree, a key you expected to see rendered twice but only see once is a reasonable signal to go back and check your source for an accidental repeat.
Why a Long ID Number Changes After You Click Format
JSON has no limit on integer size, but JavaScript's number type does. Numbers past 9,007,199,254,740,991 cannot be stored exactly, so a long ID silently rounds to the nearest value that fits, with nothing to warn you it happened.
{"id": 900719925474099123}{
"id": 900719925474099100
}Every number in a JSON document parsed by this tool, or by any JavaScript engine, gets stored as a 64-bit floating-point value. That format can represent every integer exactly only up to 9,007,199,254,740,991, a boundary defined by the language itself as Number.MAX_SAFE_INTEGER. Feed it a larger integer and it rounds to the closest value the format can actually hold. Above, an 18-digit ID ending in ...099123 comes back ending in ...099100. Both before and after are perfectly valid JSON by the specification's rules; only the digits changed, silently.
This matters most for the large integer identifiers that show up constantly in real systems: Discord and Twitter snowflake IDs, some database primary keys, and certain financial or telemetry values represented as big integers rather than strings. Format, Minify and Fix all round-trip your data through a parse-and-rewrite cycle, so any of the three can quietly corrupt an ID this way, not just Format.
Treat IDs past 15 or 16 digits as unsafe to run through this tool. If a payload contains identifiers that long, verify the digits by eye before and after, or better, work with a JSON library built for arbitrary-precision integers, or one that reads those specific fields as strings. A schema that represents large IDs as quoted strings never hits this boundary at all, since the precision limit only applies to the numeric type.
Why Formatting Can Silently Reorder Your Object's Keys
Keys that look like numbers jump to the front. Any key such as "2" or "10" gets moved ahead of every ordinary string key and sorted in ascending numeric order, regardless of where you originally wrote it.
{"b": 1, "10": 2, "a": 3, "2": 4}{
"2": 4,
"10": 2,
"b": 1,
"a": 3
}Look closely at that result: "2" and "10" move to the very front, ahead of "b" even though "b" was written first, and they land in numeric order, 2 before 10, not the order they appeared in the source. The ordinary string keys "b" and "a" keep their original relative order behind the numeric-looking ones.
This is standard behavior defined by the JavaScript language specification for how object keys are enumerated, not a quirk specific to this tool. Any key that parses as a non-negative integer, no leading zero, no decimal point, no sign, is treated as an array-like index for ordering purposes and sorted numerically ahead of everything else. It is easy to miss until it happens to data you were not expecting to change shape at all.
Where this actually bites: JSON where object keys happen to be numeric strings used as an index, IDs, an array-like structure represented as an object, or spreadsheet rows keyed by row number. If your data never uses numeric-looking keys, formatting never reorders anything and insertion order is preserved exactly as written.
Why You Should Never Commit Minified JSON to Git
A minified file turns every change into a whole-line diff. Since the entire file is technically one line, changing a single value anywhere in it makes a diff tool report that the whole line changed, hiding what actually moved.
{"id":42,"active":true,"tag":"draft"}{
"id": 42,
"active": true,
"tag": "draft"
}Minified JSON exists for machines. Stripping every space and line break shaves real bytes off a payload that gets sent over a network repeatedly, which matters for a public API response served millions of times and barely matters for a config file read once at startup. Pretty-printed JSON exists for people: one property per line with consistent indentation is what actually makes a large configuration file or an API response readable.
The version control cost of getting this backwards is easy to underestimate. Store the minified version of that object in Git and change only "tag": "draft" to "tag": "final", and a reviewer sees the whole line flagged as changed, because the whole file is one line. They cannot tell from the diff alone whether one field changed or the entire structure was rewritten. Store the formatted version instead and the same edit produces a one-line diff pointing straight at "tag".
The key-reordering behavior covered above compounds this problem. Two tools that format the same underlying data slightly differently, or an object that happens to contain numeric-string keys, can produce a diff that looks alarming even though the data underneath did not meaningfully change.
Keep a formatted source, generate a minified build. Editing minified JSON directly, then trying to review the diff, fights the format at every step. Keep the readable version under version control and produce the minified copy as a build step instead.
How to Find One Wrong Field in a Deeply Nested Response
Tree view turns nested JSON into a collapsible outline. Every object and array can be folded independently and is labeled with how many keys or items it holds, so you can collapse what you already understand and focus on the one branch you are actually investigating.
Tree parses your JSON the same strict way Validate does, so it needs syntactically correct input to work at all. Click it on broken JSON and you get the same parser error Validate would show, not a partial tree built from whatever happened to parse.
| Value type | How it appears in the outline |
|---|---|
| String | Shown in green, quoted, labeled string |
| Number | Shown in blue, unquoted, labeled number |
| Boolean | Shown in amber, labeled boolean |
| Null | Shown in gray italics, labeled null |
Object and array branches carry their own label instead of a type name: an object shows how many keys it has, an array shows how many items, and both counts update at every level of nesting. Pasting {"user":{"id":1,"tags":["a","b"]}} gives a root object holding 1 key, which expands into an object holding 2 keys, one of which is an array holding 2 items. Each of those pieces can be collapsed on its own, so a response with dozens of nested objects does not force you to scroll through all of them at once.
Type mismatches jump out visually in a tree that they hide in plain text. A quoted number that should have been numeric, or a null sitting where you expected an empty string, is easy to read past in a wall of formatted JSON but stands out immediately once color-coded by type in an expanded outline.
Six Ways People Actually Use This Tool
Debugging an API response that failed to parse
Paste the response body and click Validate first. The exact character position it reports is usually enough to jump straight to the malformed section, a missing comma or an unescaped character, rather than reading the whole payload by eye.
Cleaning up an object literal copied from JavaScript source
Code copied out of an application file often uses single quotes and skips quoting keys entirely, both valid JavaScript, neither valid JSON. Fix handles both automatically for straightforward cases. Run Validate afterward to confirm the repair actually produced parseable JSON rather than assuming it worked.
Shrinking a config file before it ships
A file edited by hand benefits from Format's readability. The same file bundled into production benefits from Minify's smaller footprint. Keep a formatted source version and generate the minified copy at build time rather than hand-editing an unreadable single-line file whenever a value needs to change.
Reviewing an unfamiliar payload before writing a type for it
Before writing a parser or a type definition against a new API response, run a sample through Tree view to see its actual shape: which fields are objects versus arrays, which values are ever null. An outlier record, a field that is a string everywhere except one object where it is a number, stands out in an expanded tree far faster than it does in a wall of minified text.
Committing readable diffs instead of whole-line noise
Keep JSON fixtures and config files formatted rather than minified before they go into version control. A one-property-per-line file produces a diff that shows exactly which field changed; a minified one shows the entire file as changed the moment any single value does.
Protecting large ID fields from silent rounding
If a payload carries snowflake-style IDs or large database keys as raw numbers, do not round-trip that specific field through Format, Minify or Fix without checking the digits afterward. Where you control the schema, storing the ID as a quoted string sidesteps the precision limit entirely, since the 2^53 boundary only applies to JSON's numeric type.
Frequently Asked Questions
Related Tools
🔒 100% Private and Secure
All JSON processing happens locally in your browser your data is never uploaded. Safe for API keys, configs, and sensitive data.