JSON Minifier

JSON Minifier

What the JSON minifier does

This page removes unnecessary whitespace from a JSON document. It parses the input, then re-encodes it without indentation or line breaks. The result is a compact string that is easier to send in a request body, store in a small record or paste into a field with a length limit. The input limit is 200,000 characters, and the conversion happens on the server. It is not a compressor and will not reduce the size of repeated values.

How to use it

Choose JSON as the language and Minify as the mode. Paste the document into the editor, or load a public JSON endpoint through the URL tab. Press the format button. The minified result appears in a read-only editor along with input and output character counts. Use copy for the clipboard or download for a .json file. If the input is invalid, the page shows an error rather than a partial result.

Minify versus beautify

Minify removes spaces, tabs and line breaks. Beautify adds indentation so a human can read the structure. They use the same parser and the same underlying round-trip, so the same edge cases apply. Minify is the better choice when you need a small payload; Beautify is the better choice when you need to review the data. Neither mode validates the schema or checks that the values are correct.

The empty-object edge case

The server decodes JSON into a PHP array before re-encoding it. An empty object written with braces can come back as an empty array written with brackets. That is a type change, even though both are valid JSON. If an API or a schema distinguishes an object from an array, inspect that field before sending the minified output. This is the most common way a minify step can surprise you.

Numeric string keys

Keys that look like integers can be treated as list indexes during decoding. A document with keys 0, 1 and 2 may come back as an array instead of an object. That changes the shape of the data. If your JSON deliberately uses numeric string keys, keep the original or use a parser that preserves object keys and types exactly.

Duplicate keys and large numbers

When a key appears more than once, the parser keeps one value and loses the other. Large integers can also lose precision when they pass through a floating-point representation. Identifiers, snowflake IDs and money stored in minor units deserve a careful before-and-after comparison. A smaller output is not automatically a safer output.

When minified JSON is useful

Minified JSON is common in HTTP request bodies, configuration strings, environment variables, queue messages and log lines. It saves space and avoids whitespace-sensitive parsing problems in systems that expect a single line. It is also easier to embed in a shell command or a URL-encoded form, provided the receiving system handles escaping. Use it when compactness matters, not just because smaller looks cleaner.

What minify cannot do

It cannot make invalid JSON valid. It does not remove duplicate keys in a helpful way, repair a trailing comma or convert single quotes. It does not compress repeated strings, deduplicate arrays or encrypt the payload. It does not guarantee that the output will fit a specific byte limit; the character count on the page is not the same as the byte count after UTF-8 encoding.

Testing before deployment

Keep the original document. Send the minified version through the same parser or API client that will consume it in production. Check that empty objects, numeric keys and large IDs survived. Compare the number of top-level keys and array lengths. If the payload is signed, hashed or compared byte-for-byte, do not minify it after signing; that will invalidate the signature.

Limits and server processing

The server accepts up to 200,000 characters and parses with a depth limit of 512. Very large or deeply nested documents should be processed locally. URL loading is also capped after download. The result is returned to the browser; the page does not publish or store it. If a request is rejected, split the document or use a command-line tool.

Privacy and sensitive data

JSON often contains tokens, customer records or internal configuration. Manual input is sent to the server for parsing, and URL loading happens server-side. Do not paste secrets or personal data unless you accept that handling. For confidential payloads, use a local tool such as jq and keep the data inside your own environment.

Common problems

If the output is unchanged, the input may already be minified. If an object became an array, look for numeric keys or an empty object. If a large number changed, precision was lost. If the page reports an error, check for comments, trailing commas or single quotes. If the output is too large for a field, the limit is probably counting bytes rather than characters.

What not to do

Do not use minify as a security measure. Do not assume the byte size matches the character count. Do not minify a signed payload after signing. Do not paste production secrets. Do not use the output without testing the receiving parser. Do not expect the page to preserve duplicate keys or exact numeric types.

Signed payloads and checksums

Some APIs sign the exact bytes of a request body, and some systems compare a checksum of the stored JSON. Minifying after signing changes those bytes and invalidates the signature or checksum. If a payload is signed, minify it first, then sign the minified bytes, and send exactly those bytes. Do not let a proxy or a formatter rewrite the body afterwards. The page has no way to know whether your payload is signed, so this check is your responsibility.

Checking byte size

A character count is not a byte count. Non-ASCII text, emoji and some punctuation take more than one byte in UTF-8. If an API limit is expressed in kilobytes, measure the encoded bytes rather than the visible length. A minified string can still exceed a small field limit.

Frequently Asked Questions