Why my formatter stack shrank to 6 tools in 2026

Six free tools cover nearly every formatting job I hit: jq for JSON, Prettier for web files and Markdown, sqlfluff for SQL, xmllint for XML, lnav for logs, and a page of client-side browser formatters for quick pastes when I don't want a terminal. All of them cost nothing. The one I dropped was pgFormatter, mostly because our SQL stopped being Postgres-only.

Quick disclosure: the formatter page I link to below is one I built. I'd tried something like 11 online formatters, and every one either sent my paste to a server I couldn't vet or buried the output under ads. That's a real problem when the paste is a production log full of customer emails. Mine runs client-side in your browser, so nothing gets uploaded and there's no account to make. If you have a better one, tell me.

Why I stopped treating formatting as an afterthought

Back in August 2026 I spent a week moving a billing service off a legacy queue. Most of that week wasn't writing code. It was staring at things: a 1.3MB JSON payload with no line breaks, a SOAP response from a payment provider that still speaks XML, and a 4,312-line log file where the one error I cared about sat on line 238 (I found it eventually, after scrolling past it twice).

The worst moment was a pull request. Someone's editor had reflowed every SQL query in the migration folder, so a three-line fix showed up as a 600-line diff. We lost 47 minutes in review arguing about whether a JOIN had changed.

It hadn't.

That's when I sat down and decided which formatter owns which file type, then wrote it into the repo instead of leaving it to whatever plugins each person happened to have installed. Formatting is boring. Unformatted text is expensive. What follows is the stack that survived that week and the two months after it.

The tools I actually keep open

Five of these get real detail below. The browser page and the tool I dropped live in the table further down.

jq

jq is the first thing I install on a new machine, before my dotfiles even. jq . pretty-prints anything you pipe into it. jq -S . sorts keys, which is the trick for diffing two API responses that return the same fields in a different order. I use that one weekly.

Where it bites: jq is strict about JSON. Trailing commas, comments, single quotes, any JSON5-flavored config file, and it'll refuse. That's correct behavior, honestly. It still annoys me every time I point it at a tsconfig.json that has comments in it and get a parse error instead of output.

Prettier

Prettier handles the web-shaped files for us: JavaScript, TypeScript, CSS, HTML, Markdown and YAML. I like it mostly because it has so few options. There's nothing to bikeshed. You pick a print width, maybe a quote style, and then nobody on the team gets to have opinions about indentation ever again.

The catch is coverage. SQL and XML only work through community plugins, and I've had mixed luck with both, so I don't route those through Prettier at all. One tool per file type, no overlap. That rule alone killed most of our formatting churn.

sqlfluff

sqlfluff is the reason that 600-line diff never happened again. It's a linter that can also rewrite your SQL (sqlfluff format for layout only, sqlfluff fix if you want rule fixes applied too), and it knows a long list of dialects. We run Postgres for the app and BigQuery for analytics, and nested .sqlfluff config files let each folder declare its own dialect.

It's slow, though. On a big migration file it can take several seconds, and in a pre-commit hook that adds up fast. I've learned to live with it. I'm still not sure whether the slowness comes from the templating support or just the parser, and I haven't cared enough to profile it.

xmllint

xmllint ships with libxml2, so on macOS and most Linux boxes it's already there. xmllint --format file.xml indents the thing. xmllint --noout file.xml just tells you whether it's well-formed, and that second command has saved me more time than the first, because half the "formatting" problems I get from that payment provider turn out to be malformed XML.

Error messages are terse. You get a line number and a vague complaint. Good enough, mostly.

lnav

lnav isn't a formatter in the strict sense, but logs are where I do the most reformatting by hand, so it earns a spot. Point it at a file or a whole directory and it detects common log formats, colors timestamps and levels, and merges multiple files into one timeline. You can also query log lines with SQL, which felt like a gimmick right up until I used it to count 1,247 timeout errors by hour during that billing migration.

It's terminal-only and the keybindings take a while to stick. I still forget half of them and end up reopening the help screen.

Side by side

Pricing is free across the board, which made the dealbreaker column the interesting one. The browser row is the client-side formatter collection on aidevhub I mentioned up top. It covers JSON, SQL, XML and HTML formatting, a Markdown preview, a log parser, plus JS and CSS minifiers, for the moments when I'm on someone else's laptop or just want to eyeball a paste.

Tool	Best for	Pricing	The one dealbreaker
jq	Pretty-printing and querying JSON in the terminal	Free, open source	Rejects JSON with comments or trailing commas
Prettier	JS, TS, CSS, HTML, Markdown, YAML in a repo	Free, open source	SQL and XML need community plugins
sqlfluff	Formatting and linting SQL across dialects	Free, open source	Slow on large files and in pre-commit hooks
xmllint	Indenting and validating XML	Free, ships with libxml2	Terse error messages
lnav	Reading and querying big log files	Free, open source	Terminal-only, steep keybinding curve
aidevhub formatters	Quick pastes in a browser, no install	Free, no signup	It's a web page, so it won't run in CI
pgFormatter	Postgres-only SQL shops	Free, open source	Built around PostgreSQL syntax

And here's the glue. This is the pre-commit script that lives in our repo now. It formats staged files by extension and re-stages them, so nobody has to remember which tool owns which file.

#!/usr/bin/env bash
# fmt-staged.sh: format staged files by extension, then re-stage them
set -uo pipefail

# reformat <file> <command...>  (command must print formatted output to stdout)
reformat() {
  local f=$1; shift
  local tmp
  tmp=$(mktemp)
  if "$@" "$f" > "$tmp"; then
    cat "$tmp" > "$f"   # cat instead of mv keeps the original file permissions
  else
    echo "skipped $f (formatter failed)" >&2
  fi
  rm -f "$tmp"
}

git diff --cached --name-only --diff-filter=ACM | while IFS= read -r f; do
  case "$f" in
    *.json) reformat "$f" jq --indent 2 . ;;
    *.xml)  reformat "$f" xmllint --format ;;
    *.sql)  sqlfluff format --dialect postgres "$f" || echo "skipped $f" >&2 ;;
    *.js|*.ts|*.css|*.html|*.md|*.yml|*.yaml)
            npx --no-install prettier --write "$f" ;;
    *) continue ;;
  esac
  git add "$f"
done

It assumes jq, xmllint, sqlfluff and a local Prettier install are present. Swap the --dialect flag for yours, or drop it if your .sqlfluff config already sets one. When a formatter fails, the script skips the file and prints a warning instead of blocking the commit. That's deliberate. I'd rather see a warning than watch someone reach for --no-verify out of frustration.

The one I ditched: pgFormatter

I used pgFormatter for about two years, and I was wrong to hold onto it as long as I did. It's a good tool. pg_format is fast, the output is readable, and if your world is only PostgreSQL I'd still recommend it without hesitation.

My world stopped being only PostgreSQL last spring, when the analytics team moved to BigQuery and started committing queries into the same repo. pgFormatter is built around Postgres syntax, and BigQuery-specific bits (backtick-quoted project.dataset.table names, STRUCT literals) came out looking odd. I spent an afternoon trying config flags before admitting the tool was doing exactly what it was designed to do. We just weren't the target user anymore.

The other gap was linting. pgFormatter makes SQL pretty; it doesn't tell you that you're mixing implicit and explicit aliases, or that a column is named after a reserved word. sqlfluff does both jobs. Slower, yes. I'll take that trade.

If you're thinking of switching, one tip: run sqlfluff in lint-only mode for a week first. The first run on our repo flagged 312 issues, and fixing them all in one PR would have produced exactly the kind of unreviewable diff I was trying to get rid of. We fixed them folder by folder instead, one small PR per afternoon.

FAQ

Q: Is it safe to paste production data into an online formatter?

A: Depends entirely on where the formatting happens. Open your browser's devtools, switch to the Network tab, paste something harmless, and watch for outgoing requests. If your paste leaves the page, don't put customer data in it.

Q: Why not just use Prettier for everything?

A: Because its SQL and XML support comes from community plugins, and I'd rather use tools whose main job is that format. One owner per file type keeps the config small and the diffs predictable.

Q: Do I need lnav if I already know grep?

A: For a single small file, probably not. Once you're merging logs from several services or need counts grouped by time, lnav saves real time. I resisted it for a year and regret that a little.

Q: Which one should I install first?

A: jq. It's tiny, it's in every package manager, and you'll use it the same day.

Written with AI assistance and human review. Try the tool at aidevhub.io/group-formatter.