How to prettify json configuration files for readability
- Step 1Identify whether the file is JSON or JSONC — Pure JSON (
package.json,.eslintrc.json,app.json, K8s/JSON manifests) formats directly. JSONC (tsconfig.json,.vscode/*.json,launch.json) allows comments/trailing commas and must be repaired first. - Step 2Drop the config file onto the prettifier — Drag the
.jsonfile onto the dropzone orbrowse. It is read in-browser viafile.text()— important for config holding secrets, since nothing uploads. - Step 3Choose the indent your project standard uses — Most JS/TS projects use
2 spaces(default); some Java/Python teams use4 spaces. Match your.editorconfig. There is no tab option — a tab-standard repo needs Prettier for byte-exact agreement. - Step 4Set key sorting based on the file — Turn
Sort keys alphabeticallyON only for data-only config where order is meaningless. Keep it OFF forpackage.json(conventional grouping matters) and any config whose order is significant. - Step 5Prettify, then write back with a trailing newline — Click Prettify JSON and Copy the full output (preview truncates at 5,000 chars; Copy/Download don't). Paste over the file. Add a trailing newline if your tooling expects one —
JSON.stringifydoes not emit it. - Step 6Validate before deploying — If the config drives a deploy, run it through json-validator (or confirm it parsed cleanly here) before shipping — a malformed config that slips through fails at runtime, not build time.
JSON vs JSONC config files
The single most important distinction for config formatting. JSONC files will NOT parse here without repair.
| File | Type | Formats here directly? | Recommended sort |
|---|---|---|---|
package.json | JSON | Yes | Off (conventional order) |
.eslintrc.json | JSON | Yes | Off (extends/plugins order can matter) |
app.json / manifest.json | JSON | Yes | Optional |
| Kubernetes JSON manifest | JSON | Yes | Off (apiVersion/kind/metadata order is conventional) |
tsconfig.json | JSONC | No — repair first | Off |
.vscode/settings.json / launch.json | JSONC | No — repair first | Off |
How options map to config needs
The two real options and when each helps a config file. Nothing else is configurable.
| Option | Value | Use for config when... |
|---|---|---|
| Indent | 2 spaces (default) | Standard for JS/TS configs, .eslintrc.json, most manifests |
| Indent | 4 spaces | Your .editorconfig/house style uses 4-space indentation |
| Sort keys | Off (default) | package.json, ESLint config, K8s manifests — order is conventional or meaningful |
| Sort keys | On | Data-only config (feature flags, key/value maps) where order is irrelevant and you want stable diffs |
Per-file size limits
Config files are almost always small, so free tier handles them. Limits from the centralized JSON tier table.
| Tier | Max file size | Batch files (JSON) |
|---|---|---|
| Free | 2 MB | 1 |
| Pro | 100 MB | 10 |
Cookbook
Config files before and after formatting. Secrets are placeholders.
Minified app config made readable
ExampleA deploy step minified app.config.json. Prettify at 2-space to restore a maintainable, reviewable layout.
Input (minified):
{"port":8080,"db":{"host":"db.internal","pool":10},"flags":{"beta":true}}
Output (2-space):
{
"port": 8080,
"db": {
"host": "db.internal",
"pool": 10
},
"flags": {
"beta": true
}
}package.json — prettify but do NOT sort
Examplepackage.json relies on conventional key grouping. Format with Sort keys OFF to fix whitespace while preserving the order tools and humans expect.
Sort keys OFF (correct):
{
"name": "app",
"version": "2.1.0",
"main": "dist/index.js",
"scripts": { "build": "tsc", "test": "vitest" },
"dependencies": { "zod": "^3" }
}
With Sort keys ON the order would scramble to
dependencies, main, name, scripts, version — avoid.tsconfig.json won't parse — repair first
Exampletsconfig is JSONC. Strict parse rejects its comments and trailing commas. Run json-format-fixer first, then prettify the strict-JSON result.
Input (tsconfig.json):
{
"compilerOptions": {
"strict": true, // recommended
"target": "ES2022",
}
}
Prettifier result: invalid JSON: Expected ',' or '}' ...
Step 1: json-format-fixer -> strips // comment + trailing comma
Step 2: prettify the cleaned JSON
(Note: comments are lost. To keep them, format in your editor.)Feature-flag config sorted for stable diffs
ExampleA flat key/value flags file where order is meaningless. Sort keys ON makes any regeneration produce the same byte order, so diffs only show real flag changes.
Input:
{"newCheckout":true,"betaSearch":false,"darkMode":true}
Output (Sort keys ON):
{
"betaSearch": false,
"darkMode": true,
"newCheckout": true
}
-> next regeneration in any order yields identical bytes.Config with a secret stays local
ExampleA config holding an API key is formatted entirely in-browser. The key is never transmitted; only whitespace changes.
Input:
{"apiKey":"sk_live_PLACEHOLDER","region":"eu-west-1","retries":3}
Output (2-space, processed in your browser):
{
"apiKey": "sk_live_PLACEHOLDER",
"region": "eu-west-1",
"retries": 3
}
The apiKey value never left the tab.Errors and edge cases
Real errors and silent failures sourced from each platform's own documentation. Match the wording to the row, fix what the row says to fix.
tsconfig.json / .vscode JSON has comments
Parse errorThese are JSONC. Strict JSON.parse rejects // and /* */ comments and trailing commas with invalid JSON: Expected ',' or '}' after property value. Repair with json-format-fixer first (this strips the comments) or use your editor's JSONC formatter to keep them. Do not blindly strip comments from a config you don't own.
package.json key order scrambled by Sort keys
Convention brokenEnabling Sort keys alphabetizes package.json, pushing dependencies above name and scattering scripts. Humans and some tooling expect the conventional grouping. Always prettify package.json with Sort keys OFF — the goal there is whitespace normalization only.
Config uses tab indentation
Unsupported widthOnly 2 or 4 spaces are available. Prettifying a tab-indented config converts it to spaces, which then diffs against your baseline as a whole-file change. For a tab-standard repo, format config with Prettier (useTabs: true) instead of this tool.
Config value is a large integer
Silent precision lossA config holding a 64-bit number (a snowflake account ID, a large port range bound) above 2^53−1 is rounded on parse, silently changing the config value. Store such values as strings in config to keep them exact.
Duplicate key in a hand-edited config
Last value winsIf a config accidentally has the same key twice (easy when merging two settings by hand), JSON.parse keeps only the last and drops the first — the prettified config silently loses a setting. Review for duplicate keys before formatting; json-validator can help spot structural issues.
ESLint config order matters and Sort breaks it
Order changedIn .eslintrc.json, the order of extends and plugins entries (arrays) is preserved, but sorting object keys can move rules relative to extends in a way that reads oddly. ESLint doesn't require alphabetical keys — leave Sort keys off to keep the config in its intentional structure.
Environment-variable placeholders like ${VAR}
Preserved (as strings)Some config formats embed ${ENV_VAR} or {{token}} placeholders. If they sit inside JSON strings ("host": "${DB_HOST}") they are valid JSON and pass through unchanged. If they are bare (unquoted) they are not valid JSON and will fail to parse — that file is a template, not JSON.
Missing trailing newline after paste-back
By designJSON.stringify does not append a final newline, so pasting the output over a config file can drop the eol-last newline your linter expects. Add it back manually, or let Prettier/your editor enforce the final newline. This is expected output, not a defect.
Number canonicalization changes a config literal
By design"timeout": 30.0 becomes 30 and "ratio": 0.50 becomes 0.5. The value is identical but the literal text changes, which can surprise a reviewer. Standard JSON round-tripping — note it if you byte-compare against the original.
Config file over the tier limit
Rejected — over tier limitConfig files rarely exceed 2 MB, but a giant generated manifest could be blocked on free tier (Pro: 100 MB). For very large manifests, a CLI formatter is a better fit, and the in-browser preview truncates at 5,000 characters (display only).
Frequently asked questions
Can I prettify package.json without breaking its key order?
Yes — leave Sort keys OFF. The tool preserves your object's key order (except numeric-string keys), so it normalizes whitespace while keeping name/version/scripts/dependencies in the conventional grouping that tools and humans expect. Only enable sorting for data-only config where order is irrelevant.
What happens if my config has trailing commas or comments?
It won't parse. tsconfig.json and .vscode/*.json are JSONC, which allows comments and trailing commas, but this tool uses strict JSON.parse. Repair them with json-format-fixer first (note: that strips comments) or use your editor's JSONC formatter to keep the comments intact.
Does it support tab indentation for my config?
No — only 2 or 4 spaces. Formatting a tab-indented config here converts it to spaces and creates a whole-file diff against your baseline. For a tab house style, use Prettier with useTabs: true so config files stay byte-consistent.
Is it safe to prettify a config that contains API keys?
Yes. The file is read with file.text() and formatted entirely in your browser — API keys, connection strings, and secrets never reach JAD Apps servers. The output is whitespace-only changed, so the secret values are preserved exactly. Only an anonymous run counter is stored when signed in.
Will sorting keys help my config diffs?
Only for data-only config (flat flag maps, key/value settings) where order is meaningless — there, a deterministic sorted order makes regenerated files produce no-op diffs. For package.json, ESLint config, and manifests, sorting breaks conventional order and harms readability, so leave it off.
Why did a numeric config value change after formatting?
Two reasons. If the number exceeds 2^53−1 it is rounded on parse (store large numbers as strings). Otherwise it is canonicalization: 30.0 → 30, 0.50 → 0.5. The mathematical value is unchanged; only the literal text differs. This is standard JSON round-tripping.
Does the tool keep my ${ENV_VAR} placeholders?
If they are inside JSON strings ("url": "${API_URL}"), yes — they pass through unchanged as string content. If the file uses bare unquoted placeholders, it is a template, not valid JSON, and won't parse. Render the template to real JSON first, or format it as a template with the appropriate tool.
How do I validate a config before deploying?
If it formats cleanly here, it is syntactically valid JSON. For an explicit check with line-accurate errors, run it through json-validator. Note that neither tool checks the config against a schema — for that, generate one with json-schema-generator and validate with an AJV-based checker.
Can I format all my config files at once?
One per run (free JSON batch is 1 file). For a repo-wide config sweep, use Prettier (npx prettier --write '**/*.json') in a pre-commit hook. Use this tool to spot-fix a single config or to quickly check that a hand-edited file still parses.
Will the output have a trailing newline?
No — JSON.stringify does not add one. Many linters (eol-last) and POSIX conventions expect a final newline in config files, so add it back after pasting, or let your editor/Prettier enforce it consistently across the repo.
Can it preserve comments in my config?
No tool that round-trips through JSON.parse can keep comments, because JSON has no comment concept — the parser discards them. For config where comments are documentation you must keep (tsconfig.json), format with your editor's JSONC-aware formatter rather than this strict-JSON tool.
Can I automate config formatting without the browser?
Yes on Pro: the json-prettifier runner mirrors this tool (indent 2/4, optional sortKeys, trim-then-parse) and processes config locally so secrets never leave your machine. For a CI gate across many config files, Prettier with prettier --check is usually the better choice.
Privacy first
Conversion runs locally in your browser. No file is uploaded — only metadata counters are saved for signed-in dashboard stats.