In March I inherited an email template from a colleague. The file was a build artifact: tens of thousands of characters packed into one line inside body, and in the editor I had to scroll sideways through more than forty screens to find a closing tag. What I needed to change was tiny, one class name on a div. It took me almost twenty minutes, and along the way I deleted part of a comment that had been swallowed into the same line. Since that day I have a rule: when I get minified source, the first thing is not to read it but to spread it out; and conversely, for a page going live, I am reluctant to leave the structural indentation in place.
Beautifying and minifying are not two sides of one action
Many people think of these as add newlines and remove newlines, as if going back and forth returned the file to its original state. In fact only one direction is reversible: beautifying reinserts newlines and indentation according to tag nesting, while minifying deletes all whitespace and newlines. A minified file carries no record of where the line breaks were or how wide the indentation used to be; beautify it again and you get the tool's own layout by nesting depth, not the version the original author typed.
This matters badly in version control. Suppose the repository holds the minified version and one day you spread it out and commit; the diff treats the whole file as one line deleted and hundreds added, and no one can review it. The more common case is the other one: the previous person used 2 spaces, you reformat with 4 and commit, so every line is marked as changed and the two lines you actually touched are buried. What I settled on: the repository stores one form, usually beautified, minification happens only in build artifacts and never enters the repository, and once an indent width is chosen for formatting it is not switched casually.
<div class="wrap"><p>first paragraph</p><p>second paragraph</p><ul><li>item</li></ul></div>Spread out, it looks like this. What I care about is seeing the hierarchy at a glance, with closing tags at the same indent depth as their opening tags:
<div class="wrap">
<p>first paragraph</p>
<p>second paragraph</p>
<ul>
<li>item</li>
</ul>
</div>2 spaces, 4 spaces or Tab: how I choose
In HTML Formatter you pick the indentation first, from 2 spaces, 4 spaces or Tab. The choice has no inherent merit, only the value of matching everyone else. I estimate by nesting depth: if the structure regularly reaches the fourth or fifth level, 2 spaces keeps code off the right edge of a narrow editor, while 4 spaces is easier to read. Once it is fixed there is a checkable pattern: for the same structure, the character count at each level is calculable.
| Nesting level | Leading spaces with 2-space indent | Leading spaces with 4-space indent | Tab indent |
|---|---|---|---|
| Level 1 | 0 | 0 | 0 |
| Level 2 | 2 | 4 | 1 |
| Level 3 | 4 | 8 | 2 |
| Level 4 | 6 | 12 | 3 |
| Level 5 | 8 | 16 | 4 |
Why I bother counting: switch from 2 spaces to 4 and a line at level 5 gains 8 leading spaces, its content changes, and the diff inevitably marks it as edited. Conversely, if one person uses Tab and another uses spaces, the same file looks misaligned under two editor settings, but that is a difference in display width, not in code.
Some whitespace removed by minification is needed for rendering
When the browser parses HTML it collapses runs of whitespace and newlines into a single space. That is why line breaks and indentation between tags usually make no visible difference, and it is the safe boundary for beautifying. Once inline elements are involved, though, that collapsed space exists: between two inline blocks separated by a space, even replacing the space with a carriage return usually still renders one space width; and the trick of setting font-size to 0 to remove the gap breaks as soon as whitespace handling changes.
More directly, content in pre and textarea is whitespace that is meant to be displayed, so it cannot be deleted as formatting noise. The minify mode in HTML Formatter keeps the content of pre and textarea intact, and even so I grep both after minifying to confirm code samples and signature boxes were not flattened.
Email templates are the last place I would format casually
Back to that template. Email HTML and web pages do not behave alike: clients handle whitespace inconsistently, and a newline between inline elements really does become a space width in some clients; when table cells use display as inline blocks for layout, adding a newline in the source can knock the layout askew. So my order for email templates is: decide first whether it needs spreading out at all, use the spread version only for the step where you need to understand the structure, then compress it back before committing. If the file is a template going live, I do not push the beautified version straight into the sending pipeline; I send myself a test email first and check whether the spacings that depend on whitespace have changed.
Another lesson is not to leave comments in a minified line. Minification can make a comment swallow the code that follows, which I only understood after deleting part of a comment that day. In templates I mark editable regions with comments, so after minifying I always confirm those markers are still there.
When to beautify and when to minify
| Situation | Direction | Reason |
|---|---|---|
| Build artifacts and source pulled from production, all on one line | Beautify | I need to read the structure and locate a tag |
| Hand-written HTML going live, where size matters | Minify | Remove newlines and indentation to cut transferred characters |
| Committing to a repository and asking someone to review | Beautify | The diff shows only the lines actually changed |
| Email templates and pages with code samples | Check after beautifying, check before minifying | Whitespace affects rendering; pre and textarea content must not change |
| Tracking down unclosed tags or messy nesting | Beautify | Indent depth reveals a closing tag in the wrong place |
When minifying I look at the original character count, the result count and the ratio, but I do not treat them as a performance verdict: one pass usually saves only a few hundred to a few thousand whitespace characters, and page speed is mostly not decided by that. What those numbers really tell me is scale: an unusually high ratio means the source had a lot of whitespace, and a ratio near 0 means the file was already minified and doing it again is wasted work.
A few things people often ask
Q: Does beautifying change how the page displays?
In the vast majority of cases it does not, because newlines between tags collapse into whitespace and browsers ignore extra whitespace. The places that do break are pre, textarea, and layouts that depend on spacing between inline elements; those need separate attention.
Q: If minification causes a problem, can I restore the original?
Not exactly. The original line breaks and indent widths were not preserved, so beautifying a minified file gives a version laid out by nesting level. That is why I never minify the only copy.
Q: When I inherit a one-line file, should I spread out the whole thing or just a fragment?
The whole file is less trouble, because reading structure needs the big picture. But when committing back, I overwrite with the minified version and copy in only the spots I changed, so formatting does not ripple through the whole file.
Q: Which is more correct, Tab or spaces?
Neither is more correct; the rule is one per project. The problem with Tab is that its width depends on editor settings, so two people see different alignment in the same file, while spaces are always consistent. When they are mixed, I lean toward converting everything to spaces.
Q: CSS and HTML are in separate files; should they be processed together?
I keep them separate. A stylesheet has different line-break rules and a different blast radius from tag structure, so I run the stylesheet through its own pass, check whether the styling has collapsed, and only then touch the HTML.
That one-line email template did get fixed, and it took longer than expected, not because I could not find the class but because spreading it out revealed two closing tags in the wrong place, all hidden inside one line in the minified version. My rule now: to understand, review or debug, always beautify; to publish and cut size, minify; and whenever someone else will keep editing the file, the copy in the repository must be readable, with minification left to the build.