Text Formatter

These are different operations that overlap in a useful way.

For JSON, formatting requires parsing, and parsing requires the input to be valid. So a formatter is a validator by side effect: if it produces output, your JSON is syntactically correct, and if it errors, it tells you where. That error position is often the fastest way to find a missing comma in a large document.

For SQL and CSS the relationship is weaker. Both can be re-indented on a fairly shallow reading of the text, so a formatter will happily lay out a query that references a table which does not exist, or CSS with a property name that means nothing. Formatting tells you the shape is plausible. It does not tell you it works.

The practical upshot: if JSON formats, it is valid JSON. If SQL formats, you have learned only that the brackets balance.

A handful of problems account for most invalid JSON, and the error message rarely names them directly.

Trailing commas. Valid in JavaScript object literals, invalid in JSON. Something written by hand, or copied out of a code file, very often has one.

Single quotes. JSON requires double quotes for both keys and string values. A JavaScript object pasted in as-is will fail on this immediately.

Unquoted keys. Again fine in JavaScript, not in JSON.

Double-encoded strings, where a JSON document has been serialised into a string and embedded inside another one. You can spot it by the backslashes before every internal quote. It needs unescaping once before it will parse.

And the invisible one: a byte order mark or a stray non-printing character at the very start of the file, usually from a Windows text editor. The document looks perfect and fails at position zero, which is a genuinely baffling error until you know to look for it.

Long queries are written incrementally and end up as a single line because that is how they came out of the tool that generated them. Reading one is genuinely hard, and the difficulty is not incidental - most SQL mistakes are structural.

Once a query is laid out with each clause on its own line and joins indented under the tables they attach to, the common errors become visible rather than hidden: a join condition that was never written, so the query is producing a cross product; an OR inside a WHERE clause without brackets, which binds differently from what the author meant; a GROUP BY that does not cover every non-aggregated column.

None of these are syntax errors. They all run. They just return the wrong rows, which is a considerably worse failure than a query that refuses to execute, because nobody notices.

One caution: format queries you are reading, not necessarily queries in version control. Reformatting a large query wholesale produces a diff that touches every line and hides whatever you actually changed. If a project has a house style, follow it rather than imposing a formatter's.

The JavaScript, TypeScript and CSS formatting here is indentation and line breaking. It is enough to make minified or badly laid out code readable, which is what you usually want when you have been handed something and need to understand it.

It is not a substitute for a real code formatter in a codebase. Prettier, gofmt, Black and their equivalents encode a full opinion about line width, quote style, bracket placement and how to break long expressions, and they are configured per project so everyone's output matches. Running arbitrary text through a different formatter and committing the result creates noise for everyone else.

The honest division of labour: use this to read something, use your project's formatter to write something.

Two more things worth knowing. Comments and blank lines are structural to humans and invisible to a naive formatter, so they can be moved or lost. And minified code that has been through a bundler has had its variable names shortened - formatting restores the line breaks but nothing restores the names, so it will be readable and still not friendly.