Base64 Encoder and Decoder
Text to Base64 and back again
Paste messy JSON to format, minify or validate it. Numbers come back exactly as you typed them, and invalid JSON gets the browser's own parser message.
Parsed in your browser. Nothing is uploaded.
It never leaves your device.
This one runs entirely in your browser. Nothing you type or drop here is sent to us, so there is nothing on our server to keep, and nothing to delete. It works offline once the page has loaded.
No, and it is the one thing most formatters get wrong. Every number is copied across as the digits you typed, so a 64-bit id like 12345678901234567890 comes back with all twenty digits, where a formatter that reads JSON into a JavaScript number first hands back 12345678901234567000. A number too large for a double stays as you wrote it instead of turning into null. The cost of doing it this way is that a number keeps its spelling: 1.5e10 stays 1.5e10 rather than being rewritten to 15000000000, and 1.0 stays 1.0. So the output is not always byte-identical to another formatter's, but the values are always the ones you pasted.
Format indents two spaces for each level of nesting and puts a space after every key. Minify strips all of it and gives you one line. Both run through the same code and neither alters a value, so you can move back and forth as often as you like without your data drifting. The one thing that is re-spelled either way is an escape inside a string: "caf\u00e9" comes back as "café" and "a\/b" as "a/b", which is the same text written the canonical way.
No. Both the checking and the formatting happen inside the page you are looking at, which is why it says "Parsed in your browser. Nothing is uploaded." under the buttons. There is no server step, so there is no size limit set by us and nothing waiting to be deleted afterwards. The only ceiling is how much your own browser can hold at once.
They are your browser's own JSON parser messages, passed through word for word rather than swapped for something friendlier, because the browser's are more precise. A structural mistake comes with a place in the text: a trailing comma reads "Expected double-quoted property name in JSON at position 7 (line 1 column 8)". The commoner case of an unexpected word gives a snippet instead, so {"a":NaN} reads "Unexpected token 'N'" and the start of your input, with no line or column. That is why this page promises a line and column only where the parser can give one.
No. This validates against JSON as specified, not a relaxed variant of it, so a trailing comma, an unquoted key, a single-quoted key, a // comment, NaN, Infinity, a leading zero like 01, and anything left over after the closing brace are all refused, each with the parser's own message. A file that needs those is JSON5 or JSONC rather than JSON, and it will not pass here.
Both copies stay in the output. JSON permits the same key twice and a parser keeps the last one, so {"a":1,"a":2} is really a value of 2 plus a mistake further upstream. A formatter that hands back {"a":2} has hidden that from you; this one leaves both lines on screen so you can see the duplicate and go and fix whatever wrote it.