Formatters Tools
Beautify and format code for better readability. Support for JSON, XML, YAML, SQL, HTML, CSS, and JavaScript.
Messy, minified, or inconsistently indented code is a debugging tax you pay on every read. These formatters normalize JSON, XML, YAML, SQL, HTML, CSS, and JavaScript to a consistent style - so you can spot the actual problem instead of fighting the formatting.
9 tools availableJSON Formatter
Format, validate, and beautify JSON data
XML Formatter
Pretty print and validate XML documents
YAML Formatter
Format YAML with syntax validation
SQL Formatter
Beautify SQL queries with proper indentation
HTML Formatter
Prettify HTML markup with proper formatting
CSS Formatter
Format CSS, SCSS, and LESS stylesheets
JavaScript Formatter
Format JavaScript and TypeScript code
Log Parser
Parse and analyze log files with format detection
Email HTML Renderer
Preview HTML emails with client compatibility checks
Formatting is normalisation: what each grammar lets a formatter move
A formatter is safe exactly where the grammar says the characters do not matter. That is a small set in JSON, a subtle one in YAML, and a genuinely dangerous one in SQL - where the case of an identifier can name a different object.
JSON gives a formatter four whitespace characters
RFC 8259 defines the grammar tightly: "A JSON text is a sequence of tokens. The set of tokens includes six structural characters, strings, numbers, and three literal names", and then the permission that makes pretty-printing legal - "Insignificant whitespace is allowed before or after any of the six structural characters" - where whitespace means space, horizontal tab, line feed and carriage return, nothing else. Two documents with identical values may still differ in bytes: "ECMA-404 allows several practices that this specification recommends avoiding in the interests of maximal interoperability". Format for humans; compare by value.
YAML and SQL: where reformatting changes the data
YAML is indentation-scoped, and its comments "begin with an octothorpe (also called a 'hash', 'sharp', 'pound' or 'number sign' - ' # ')". The trap is the space after a colon: "Normally, YAML insists the ' : ' mapping value indicator be separated from the value by white space. A benefit of this restriction is that the ' : ' character can be used inside plain scalars, as long as it is not followed by white space." The specification says out loud why that is risky - "a potential source for confusion as ' a:1 ' is a plain scalar and not a key/value pair" - so a formatter that inserts a helpful space has changed a string into a mapping.
SQL has the same shape at a different layer. In PostgreSQL "Key words and unquoted identifiers are case-insensitive", which is why a keyword can be upper-cased freely; but "There is a second kind of identifier: the delimited identifier or quoted identifier. It is formed by enclosing an arbitrary sequence of characters in double-quotes", and "A delimited identifier is always an identifier, never a key word". Lower-casing a quoted identifier therefore renames the object. Length is a second hard edge: the server "uses no more than NAMEDATALEN -1 bytes of an identifier; longer names can be written in commands, but they will be truncated", and with the default NAMEDATALEN of 64 "the maximum identifier length is 63 bytes".
XML constrains what an attribute may contain at all
XML 1.0 includes a well-formedness constraint named "No < in Attribute Values": "The replacement text of any entity referred to directly or indirectly in an attribute value MUST NOT contain a <." A formatter that reformats XML has to treat attribute content as opaque - it is not code that can be re-indented or re-quoted.
| Format | A formatter may change | A formatter must not change | Specification |
|---|---|---|---|
| JSON | whitespace before and after the six structural characters | the characters themselves; format for reading, compare by value | RFC 8259 |
| YAML | indentation that carries structure, and comments | the space after a colon that decides scalar versus mapping | YAML 1.2.2 |
| XML | indentation between elements | attribute values, which may not contain a < even via an entity | W3C XML 1.0 |
| SQL | keyword case and layout | the case of a quoted identifier, and names beyond 63 bytes | PostgreSQL documentation |
| JavaScript | whitespace, subject to automatic semicolon insertion | line separators U+2028 and U+2029 inside string literals | TC39 JSON superset proposal |
Normalise each grammar with its own tool - JSON Formatter, XML Formatter, YAML Formatter, SQL Formatter, HTML Formatter, CSS Formatter and JavaScript Formatter - then diff the result against the original with Text Diff before committing it.
Sources: RFC 8259, JSON, section 2; YAML 1.2.2 specification, chapter 2; PostgreSQL documentation, lexical structure; W3C XML 1.0, well-formedness constraints; TC39 JSON superset proposal.