Formatting Code for Readability: JSON, HTML, CSS, and SQL

You open a file and see this:

<div class="container"><ul><li><a href="/about">About</a></li><li><a href="/contact">Contact</a></li></ul></div>

Or this:

SELECT u.id, u.name, o.total FROM users u JOIN orders o ON u.id = o.user_id WHERE o.status = 'completed' AND o.created_at > '2025-01-01' GROUP BY u.id, u.name ORDER BY o.total DESC LIMIT 10;

Both are technically correct. Both are also unreadable. Formatting transforms code from something a machine can execute into something a human can understand. That's the entire point — code is read far more often than it's written.

Why Formatting Matters

This isn't about aesthetics. Poorly formatted code has practical costs:

Bugs hide in dense code. When everything's on one line, you miss the extra closing bracket or the wrong attribute. Proper indentation makes structure visible, and visible structure means fewer mistakes.

Reviews take longer. Every minute a reviewer spends parsing formatting is a minute not spent evaluating logic. Consistently formatted code lets reviewers focus on what actually matters.

Onboarding slows down. New team members reading minified or inconsistently formatted code spend more time figuring out structure and less time understanding behavior.

Diffs become meaningless. If half a PR is formatting changes mixed with logic changes, good luck reviewing it. Consistent formatting means diffs show only meaningful changes.

JSON: The Universal Data Format

JSON formatting is probably the most common formatting task for developers. APIs return minified JSON, config files get mangled, and logs dump raw payloads.

Unformatted:

{"users":[{"id":1,"name":"Alice","roles":["admin","editor"]},{"id":2,"name":"Bob","roles":["viewer"]}]}

Formatted:

{
  "users": [
    {
      "id": 1,
      "name": "Alice",
      "roles": ["admin", "editor"]
    },
    {
      "id": 2,
      "name": "Bob",
      "roles": ["viewer"]
    }
  ]
}

Night and day. The structure, nesting, and relationships are immediately clear. Paste any JSON into the JSON Formatter and get clean, indented output with error detection.

HTML: Nested by Nature

HTML gets messy fast because of deep nesting. A few levels of div wrappers and you've lost track of which closing tag belongs where.

Good HTML formatting follows a simple rule: each child element gets one more level of indentation. Self-closing and inline elements can stay on one line if they're short.

<div class="card">
  <div class="card-header">
    <h2>Title</h2>
    <span class="badge">New</span>
  </div>
  <div class="card-body">
    <p>Description goes here.</p>
  </div>
</div>

The HTML Formatter handles the indentation automatically, even for deeply nested markup copied from browser DevTools.

CSS: Rules and Properties

CSS formatting is mostly about consistency within rule blocks:

.card {
  display: flex;
  flex-direction: column;
  padding: 1rem;
  border: 1px solid #e5e7eb;
  border-radius: 0.5rem;
  background-color: #ffffff;
  box-shadow: 0 1px 3px rgba(0, 0, 0, 0.1);
}

One property per line, consistent indentation, a space after the colon. When CSS gets minified for production, it collapses into something like .card{display:flex;flex-direction:column;padding:1rem;...} — functional but opaque.

Common formatting questions in CSS:

• Property order: alphabetical, by type (layout → typography → visual), or as-you-go? Most teams pick one and enforce it via Stylelint.
• Shorthand vs. longhand: margin: 1rem 2rem vs. margin-top: 1rem; margin-right: 2rem;. Shorthand is more compact; longhand is more explicit.
• Nesting depth: With modern CSS nesting or preprocessors, it's tempting to go deep. Try to stay under 3 levels.

The CSS Formatter cleans up minified or messy stylesheets into readable, consistently indented rules.

SQL: Readability Saves Debugging Hours

SQL formatting might be the most impactful of all. A complex query on one line is genuinely dangerous — you can't visually verify the JOIN conditions, WHERE clauses, or GROUP BY logic.

Before:

SELECT u.id, u.name, COUNT(o.id) as order_count, SUM(o.total) as total_spent FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE u.created_at > '2025-01-01' AND u.status = 'active' GROUP BY u.id, u.name HAVING COUNT(o.id) > 5 ORDER BY total_spent DESC;

After:

SELECT
  u.id,
  u.name,
  COUNT(o.id) AS order_count,
  SUM(o.total) AS total_spent
FROM users u
LEFT JOIN orders o
  ON u.id = o.user_id
WHERE u.created_at > '2025-01-01'
  AND u.status = 'active'
GROUP BY u.id, u.name
HAVING COUNT(o.id) > 5
ORDER BY total_spent DESC;

Now you can immediately see: two tables joined, two filter conditions, grouped with a HAVING clause, sorted by spend. The SQL Formatter handles standard SQL plus most dialect-specific syntax.

JavaScript: Beyond Prettier

Most JavaScript teams have adopted Prettier or a similar auto-formatter. But there are still times you need to format a standalone snippet — a code review comment, a Stack Overflow answer, or a chunk of minified production code you're debugging.

// Minified
const f=async(a,b)=>{const r=await fetch(`/api/${a}`);if(!r.ok)throw new Error(r.statusText);const d=await r.json();return d.filter(i=>i.type===b)};

Formatted:

const f = async (a, b) => {
  const r = await fetch(`/api/${a}`);
  if (!r.ok) throw new Error(r.statusText);
  const d = await r.json();
  return d.filter((i) => i.type === b);
};

The JavaScript Formatter handles ES6+ syntax, arrow functions, template literals, and async/await.

XML and YAML

These two formats are at opposite ends of the verbosity spectrum but both benefit from consistent formatting.

XML needs proper indentation even more than HTML because it's typically used for configuration and data interchange where structure is everything. An unindented Maven POM or Android layout file is painful. The XML Formatter handles deep nesting and mixed content.

YAML is whitespace-sensitive by design — indentation IS the syntax. But this means a single misplaced space can change the meaning entirely. A YAML formatter ensures consistent indentation and catches structural issues before they become runtime errors. Format YAML with the YAML Formatter.

Formatting vs. Minification

Formatting and minification are two sides of the same coin:

| | Formatting | Minification | |---|-----------|-------------| | Purpose | Human readability | Machine efficiency | | Whitespace | Added consistently | Removed completely | | When | Development, review | Production, transport | | File size | Larger | Smaller |

Both are lossless transformations — the code behaves identically. You format for development, minify for deployment, and convert between them as needed.

Try It Yourself

Stop squinting at unformatted code. Paste it in, get it formatted, move on:

• JSON Formatter — beautify, validate, and minify JSON
• HTML Formatter — indent nested markup
• CSS Formatter — clean up stylesheets
• JavaScript Formatter — format ES6+ code
• SQL Formatter — structure complex queries
• XML Formatter — indent XML documents
• YAML Formatter — normalize YAML files

Everything runs in your browser. Your code stays on your device.