Code Formatter & Beautifier

Code Formatter & Beautifier

Format and beautify JSON, XML, CSS, HTML, JavaScript, SQL code. Auto-indent and syntax highlight. Free online code beautifier and formatter

A formatter that "makes code pretty" is the boring case. The interesting case is when the formatter changes semantics — JSON5 trailing commas dropped by a strict parser, SQL keyword casing breaking case-sensitive identifiers in quoted Postgres tables, JavaScript ASI inserting semicolons where you did not want them. This formatter uses the same parsers Prettier and SQL-format do, runs locally, and tells you exactly which formatter dialect it applied so you can match production tooling.

Languages and the parser behind each

  • JSON / JSON5 — strict JSON.parse for default, json5 module for trailing commas and unquoted keys. The output is always strict JSON unless you select JSON5 explicitly.
  • JavaScript / TypeScript — Prettier ESM build (3.x) with default config. Override print width and tab width; semicolons and quote style default to the Prettier defaults you already see in the wild.
  • HTML / CSS — Prettier with @prettier/plugin-xml for XHTML, lightning-css for modern CSS-nesting.
  • SQL — sql-formatter with dialect selector (PostgreSQL, MySQL, SQLite, BigQuery, Snowflake). Different keyword sets, different quoting rules, different identifier escapes.
  • XML — fast-xml-parser then re-serialize. Preserves attribute order and CDATA blocks.
  • YAML — js-yaml round-trip. WARNING: js-yaml normalizes anchors and removes comments. For comment-preserving YAML formatting, use yamlfmt on the command line.

Working example: a tricky SQL case

Input

select u.id,u.name,count(o.id) as order_count from users u left join orders o on o.user_id=u.id where u.created_at >= '2024-01-01' group by u.id,u.name order by order_count desc limit 50

Output

SELECT
  u.id,
  u.name,
  COUNT(o.id) AS order_count
FROM
  users u
  LEFT JOIN orders o ON o.user_id = u.id
WHERE
  u.created_at >= '2024-01-01'
GROUP BY
  u.id,
  u.name
ORDER BY
  order_count DESC
LIMIT
  50

Default casing is uppercase keywords, lowercase identifiers — the Postgres convention. For MySQL backtick-quoted identifiers, switch the dialect; sql-formatter respects backticks vs double-quote escaping per dialect.

Cases where formatting changes semantics

  • JavaScript automatic semicolon insertion (ASI) — Prettier inserts semicolons by default. If your code relies on no-semicolon style (Standard JS), set --no-semi. Adding a semicolon before a line starting with [ or ( is harmless; removing one before such a line breaks the program.
  • JSON with comments — JSONC and JSON5 allow comments. Strict JSON.parse rejects them. Round-tripping through a strict formatter silently drops them.
  • YAML anchors and merge keys — js-yaml expands &anchor / *alias into duplicated subtrees during parsing. The output is logically identical but textually huge and no longer DRY.
  • SQL keyword casing in quoted identifiers — "Name" in Postgres is a different identifier than "name". A formatter that normalizes casing inside quotes will break case-sensitive queries.
  • HTML void elements — <br>, <img>, <hr> are self-closing in HTML5, /-suffixed in XHTML. A formatter targeting the wrong dialect will produce non-validating output.

When to reach for this tool

  • You pasted a minified JSON blob from a curl response and need to read it. Drop into the JSON tab, get tree-indented output, expand only the fields you care about.
  • You inherited a SQL query in a single 800-character line and want to see the join structure before editing.
  • You are reviewing a PR and want to compare two function bodies that are formatted differently — reformat both with identical rules so the diff shows real changes only.
  • You need to share a snippet on Slack / in a doc and want consistent indentation across languages without configuring Prettier locally.

What this tool will not do

  • It will not fix invalid code. The parsers reject syntactically broken input — a missing brace will produce an error, not a "best-guess" reformat.
  • It will not preserve all comments in every language. SQL block comments, YAML comments, and JSON5 comments are preserved; HTML conditional comments and CSS source-map comments may be moved.
  • It will not match every flag of every team's Prettier config. For exact reproducibility, run Prettier locally against your repo's .prettierrc. The defaults here match the widest published defaults but cannot cover every override.

Formatting runs entirely in your browser. Internal queries, secrets in JSON payloads, and proprietary SQL stay on your machine.

Frequently asked questions

Why does my formatted JSON have double quotes when my input had single?

Strict JSON requires double quotes around all strings and keys (RFC 8259). Single quotes are a JavaScript-object-literal convention, not JSON. If you need single quotes for a JS data file, format as JavaScript or JSON5, not JSON.

How is this different from running Prettier locally?

Same parser, same default rules. Local Prettier respects your project's .prettierrc; this tool uses the published defaults. If your repo has custom config, this won't exactly match — but for ad-hoc snippets it will produce the same output as a Prettier user with default settings.

Can it format a 10MB JSON file?

Yes, but JSON.parse on multi-megabyte text in the browser takes time. Expect ~200ms per MB. For very large files, format in your terminal: jq . file.json or python -m json.tool < file.json.

Why are my SQL queries reformatted with uppercase keywords?

Default convention is uppercase SQL keywords for readability against lowercase identifiers. Change the keyword-case option to "lower" if you prefer all-lowercase. The choice is purely stylistic; SQL keywords are case-insensitive in every major dialect.

Does formatting break inline comments in JavaScript?

No. Prettier preserves both // and /* */ comments. Inline comments at end-of-statement may move to the line above if the statement wraps; block comments inside function bodies stay where they are.

Will the formatter sort object keys or import statements?

Not by default. Key sorting is a separate transformation (some teams want it, most do not). For sorted JSON keys use jq --sort-keys; for sorted imports use ESLint with the appropriate plugin, run on your CI not on a web tool.

Related tools

SQL Formatter & Beautifier

Format and beautify SQL queries with syntax highlighting. Support for MySQL, PostgreSQL, SQL Server. Free online SQL formatter and pretty printer

JSON Tree Diff

Compare two JSON documents with visual tree diff. Highlight added, removed, modified nodes. Expandable tree view. Free online JSON comparison tool

Text Diff Checker

Compare two texts and highlight differences side by side. Find changes between files, code versions. Free online text comparison diff tool

Markdown Editor & Preview

Write and preview Markdown with live rendering. GitHub Flavored Markdown support. Free online Markdown editor with syntax highlighting

Code Screenshot Generator

Create beautiful code screenshots with syntax highlighting. Carbon-like code images with themes. Free online code snippet to image converter

Data Converter

Convert data between JSON, CSV, YAML, XML, TOML formats online. Free data format transformer with syntax validation and pretty printing

Last updated · E-Utils editorial team