How to Format HTML, CSS and JavaScript You Didn’t Write (and Keep Your Own Consistent)

Inheriting someone else’s code usually starts with a wall: a 3,000-line CSS file with no line breaks, a JavaScript bundle that is one enormous line, an HTML template where the indentation was destroyed by three different editors. Nothing is wrong with the code; it just cannot be read. Formatting fixes that in seconds, and once you have a formatter in your workflow it also ends the argument about tabs versus spaces, because the tool decides and everyone’s code looks the same. Here is what formatters do, the conventions worth adopting, and how to use one without introducing bugs.

What a formatter changes (and doesn’t)

A formatter rewrites whitespace, indentation and line breaks according to rules. It does not change what the code does. That is the difference from a linter (which flags problems) and a minifier (which removes whitespace for size). Feed it minified code and it becomes readable; feed it messy code and it becomes consistent.

The HTML, CSS & JavaScript Formatter takes any of the three, detects the language, and returns it indented with your choice of two spaces, four spaces or tabs. It is the manual version of what Prettier does inside an editor.

Advertisement

Conventions worth adopting

Indentation

Two spaces is the JavaScript ecosystem default (Prettier, Google, Airbnb styles). Four spaces is common in PHP, Python and older CSS. Tabs are preferred by WordPress core and some accessibility guidance (users can set their own tab width). None of these is wrong; pick one per project and never mix.

Line length

80 or 100 characters. Long lines hide bugs at the right edge and make side-by-side diffs unreadable. Formatters wrap at the limit automatically.

CSS property order

Formatters don’t reorder properties, but a convention helps: positioning first (position, top, z-index), then box model (display, width, margin, padding), then typography, then visual (background, border, box-shadow). Some teams use alphabetical. Either beats random.

HTML

One attribute per line once a tag exceeds the line length. Block elements on their own lines; inline elements can share. Indent children one level. Close every tag, even the optional ones (<li>, <p>), so the structure is visible.

Where formatting can change behaviour

Rare, but real:

1. HTML whitespace between inline elements. <a>One</a><a>Two</a> renders “OneTwo”. Put each on its own line and the browser inserts a space: “One Two”. Good formatters know this; check the result if buttons or badges shift.
2. <pre>, <textarea>, <script> content. Whitespace inside these is meaningful. A formatter should leave it alone.
3. JavaScript automatic semicolon insertion. Reflowing code that omits semicolons can, in edge cases, join or split statements. A formatter that inserts semicolons (Prettier’s default) removes this risk.
4. Template languages. Formatting a file with PHP, Blade, Liquid or JSX mixed into HTML needs a formatter that understands the template syntax, or it will treat template tags as broken HTML.

A workflow that removes the problem entirely

1. Install Prettier (or the equivalent for your stack: PHP CS Fixer, Black for Python) and turn on format-on-save in the editor. Code is formatted every time it is saved; nobody thinks about it again.
2. Commit a config file (.prettierrc, .editorconfig) to the repository so every contributor gets the same rules.
3. Add a pre-commit hook so unformatted code cannot be committed. One badly formatted commit reformats hundreds of lines and pollutes the diff.
4. Format the whole codebase once, in a single commit with no other changes, so git blame stays useful.

The online formatter covers the cases that fall outside that workflow: a snippet pasted into a page-builder custom-code box, a minified file with no source, a colleague’s email with a CSS block in it, or code you are about to paste into a forum answer.

Reading minified code you didn’t write

Formatting gives you structure but not names; a minified variable is still called e. Tactics that help: search for string literals (error messages, API paths) to find the function you care about; look for the exports at the end of a bundle; and check for a .map file next to the minified one, which DevTools uses to show the original. If you also need to shrink code after editing, the Code Minifier is the reverse step, and the JSON Formatter handles data files with the same approach.

Frequently asked questions

Does formatting code affect performance?

Not for the user, as long as the shipped file is minified. Formatting is for the source; minification is for production. Keep both.

Tabs or spaces?

Spaces are the majority choice in JavaScript and CSS; tabs in WordPress PHP and Go. Consistency within a project matters far more than the choice.

Can a formatter fix broken HTML?

It can make the structure visible, which usually reveals where a tag was left open. It won’t guess your intent; fix the tag yourself.

Is it safe to paste proprietary code into an online formatter?

The ToolzDirectory formatter runs in your browser and sends nothing to a server. For other tools, check; and for anything sensitive, use an editor plugin.