JSON Formatter & Validator
Format, validate, and minify JSON instantly in your browser. For inspecting API responses and tidying config files.
Other Tools
Related articles
📖 Where people get stuck
Formats, validates and minifies JSON in the browser. It looks like mere reformatting, but the document is parsed and written out again, so values can change — the specification does not fully determine how numbers are represented or what happens to duplicate keys, and those parts are left to the implementation. There is, in fact, no guarantee that the meaning survives the round trip.
| Case | What happens | What to do |
|---|---|---|
| A large integer changes just from being reformatted | JavaScript JSON.parse reads every number as a double-precision float, so integers above two to the fifty-third cannot be represented exactly and are rounded to a nearby value. Reformat 9007199254740993 and you get 9007199254740992, with no error and no warning. The dangerous cases in practice are large identifiers of the kind Twitter and Discord use, Snowflake ids, and BIGINT primary keys: data you reformatted and pasted back now points at a different record. The worst part is that it broke during what you thought was mere formatting, so nothing prompts you to suspect it. |
Hold large identifiers as strings — write "id": "9007199254740993" and the parser never converts it to a number, so the value survives. The Twitter API addressed this early on by returning a separate id_str field, and hold numbers you never do arithmetic on as strings is by now an established design decision in this area. When working with existing data, check first whether what you are about to format contains large integers; the test is easy — be suspicious of any value longer than sixteen digits, since two to the fifty-third is 9,007,199,254,740,992, which has sixteen. And make a habit of diffing before and after formatting: an unintended change of value shows up nowhere else. |
| Duplicate keys silently collapse into one | JSON in which the same key appears twice, such as {"a":1,"a":2}, is undefined behaviour by specification: RFC 8259 says keys should be unique but does not say what to do when they are not. Practically every implementation lets the later one win, so formatting produces {"a":2} and the first value vanishes without trace. In a configuration file this matters: the cause of a setting that does not take effect is often that the same key appears earlier in the file, and formatting destroys that evidence too. |
For configuration JSON, use a linter that detects duplicate keys — jsonlint and most editor JSON extensions will warn. A formatter cannot be used for detection, because it resolves the duplicate instead; understand the two as having different purposes. And when you do find a duplicate, ask not which one is right but why two were written: usually someone pasted in a setting without noticing the existing entry, and deleting one of them alone means it happens again. Once a configuration file grows, keeping the keys in alphabetical order makes duplicates visible to the eye. |
| JSON with comments fails to parse | Standard JSON has no comments. That is not an oversight: Douglas Crockford removed them from the specification deliberately, because comments were starting to be used as directives to parsers, which would have broken interoperability. In practice, though, configuration files that do allow comments are widespread — tsconfig.json, .vscode/settings.json, .eslintrc.json. These are a separate dialect, JSONC (JSON with Comments), and they always fail in a standard JSON parser. What you thought was JSON was not JSON is the real shape of this error. |
To work with JSONC, use a parser built for it — jsonc-parser on Node, which is what tools reading VS Code settings use. To convert commented JSON into standard JSON, strip the comments first, but the information those comments carried is lost at that moment, so never write the converted result back over the original file. More broadly: if a configuration file needs comments, choosing YAML or TOML rather than JSON is the more honest answer. A format that cannot record why a value is what it is lacks something important in a configuration file — for whoever reads it in six months, that one line of comment is frequently worth more than the setting itself. |
Formatting earns its keep most in making diffs readable. If you commit an API response to the repository as fixed test data, format it before you commit: with minified single-line JSON, a one-character change turns the whole file into a diff and review becomes impossible. Key order needs care, though: some formatters and some languages reorder keys alphabetically, in which case the first commit is an all-lines diff. Decide as a team not only whether to format but whether to sort keys, and apply it mechanically in CI — when settings differ per person, meaningless diffs bury the review. One security note to close on: before pasting an API response into any formatter, check that no Authorization header or token came along in the body. This page runs entirely in your browser, but once the habit forms of doing this in whatever online tool is to hand, sooner or later a production token goes to someone else server.
📖 How to Use
-
1
Paste JSONCopy JSON from an API response or config file and paste it into the input.
-
2
Choose format or minifyPick indent width and click Format to prettify, or Minify to compress to a single line.
-
3
Validate & fixSyntax errors show line number and reason. Copy result with one click.
❓ Frequently Asked Questions
Does it handle JSON with comments (JSON5 / JSONC)?
Is my data sent to a server?
Does it handle large JSON (10+ MB)?
Can I sort keys alphabetically?
🐛 Found a bug or issue with this tool?
Free to use, no signup. Even just the steps to reproduce are helpful. Reports go directly to the operator and help us fix issues.
Thanks for your report!
Your report has been delivered to the operator and will be used to improve the tool.