About

HTML-Crush is an Email Template-oriented minifier, differently from Web Page-oriented minifiers. While it will compress Web Pages fine too (albeit not as efficiently) but Web Page minifiers might break your email templates.

• HTML-Crush accepts non-HTML, incomplete HTML, parts of HTML — HTML-Crush does not care about code validity. Use different tools to validate your code. HTML validity is not that relevant for email templates.

• HTML-Crush minifies Email Templates which contain templating language literals, for example:

<td class="{% if count < 10 %}few{% else %}many{% endif %}>"

Usually, a random unescaped HTML raw brackets < and > will break some minifiers. But not HTML-Crush.

It's because HTML-Crush does not parse the HTML — it treats its input as text (which may or may not be HTML).

• HTML-Crush will not minify colour hex codes turning #FFFFFF into #FFF because three digit colour codes don't work well in email.

• HTML-Crush will respect conditional Outlook code. As a rule of thumb, HTML-Crush does not delete non-whitespace characters.

• HTML-Crush website you see here, or its API, npm package html-crush does not have a back-end unlike some competitors who save the compressed files and delete them every hour. There is no back-end on HTML-Crush; your code never leaves your browser and your hard drive. It's just JavaScript in HTML page you downloaded that does the job.

If your email template file size is approaching 80KB (around 80,000 characters in total if you select all in your code editor), you must use a minifier.

Email Minifying Peculiarities

Email Templates require a different minification compared to Web Pages:

• Lines have to be limited to 500-ish characters. While email specs impose 998 character line lengths, in practice, safe line lengths are around half that. Although most Web Page minifiers can limit line lengths, so it's not a unique feature of HTML-Crush.
• Even if you minified your email template with 500 character line limit on a Web Page minifier, Outlook might not render your email right. It appears that Outlook is sensitive to unexpectedly long lines that contain multiple table tags. The guaranteed-safe approach is to add additional line breaks at various places, for example, to break before </td></tr></table> or before each @media. This is a unique feature of HTML-Crush. We came up with the list of code break locations practically and added more and more until emails didn't break any more. By the way, you can override or supplement the breaking points yourself, it's the opts.breakToTheLeftOf setting in the npm package.
• Email templates often use "Outlook-only" and "all-except-Outlook HTML" comment blocks. HTML-Crush does not mangle them. Web Page minifiers can mangle conditional comment blocks, for example, they'd consider <!-- --> bit from all-except-Outlook block <!--[if !mso]><!-- --> as redundant.

While you can get away with non-minified website HTML, minifying is crucial for Email Templates because Gmail truncates emails somewhere between 80KB and 100KB and also on certain special unencoded characters outside ASCII range.

HTML-Crush is used in production by some big UK brands, but we won't name-drop.

Differently from Web Page minifiers, HTML-Crush adds extra line breaks in certain places to cater Outlook

The Algorithm

The principle of our algorithm is quite simple — delete all whitespace between certain characters, for example, closing bracket > and opening bracket <. There is more logic (to tend CSS code, to limit line length, to ensure against false positives and so on) but this is the main principle how this minifier works.

It is very wise to decouple the core of a web application from its front-end UI. This way, the core can be unit-tested separately, and other "consumers" can be plugged into it as well:

• somebody might want to tap the core API directly in Gulp
• somebody might want to drive a CLI using the core API — command line application — which is called via Terminal and can minify many files like ./templates/html/*.html (notice wildcard * which will catch many files)
• somebody might want to use the core API on a different web page, a separate tool, just as one of the features
• somebody might want to put the core API on a server-side and make it into a REST API endpoint which minifies what's posted to it
• somebody might want to put core API into an Electron app and create a desktop application which you can install

This "core API" is our npm package, html-crush, and this website is using it.

Differences between html-crush (by Codsen) and html-minifier (by Kangax):

Here are differences between html-crush and a popular Kangax html-minifier:

	html-crush by Codsen	Kangax html-minifier
Typical market	Email templates	Web pages
Strengths	Can minify HTML mixed with anything	Compresses to the maximum
On npm
Weaknesses	Can't detect if an input code is broken	Overwhelming amount of options, some of them risky
Priority	Mixed or dirty sources support at the expense of maximum compression	Maximum compression at the expense of mixed or dirty sources support
When the input contains a code error...	Minifier will not complain about it and minify it	Minifier will throw an error, and you will not get any result at all

PS. You can't make html-crush to throw an error. It's impossible. It will always minify whatever you give to it.

FAQ

Is the code I paste into this application safe?

Yes, because there is no back-end — your code never leaves your browser. This application is a bunch of static HTML, CSS and JS files, served through a secure HTTPS connection. Feel free to inspect the sources.

What framework is this website using?

We use vanilla JS, Markdown, Gulp and Nunjucks to generate a static file structure.

Why are you not using Svelte/React/VueJs/Angular here?

It would be an overkill for a simple web app like this.

How did you achieve the "loading" and why is UI responsive even while the result is being calculated?

We spin up a web worker on a separate thread.

How does this website "remember" all the settings and input even after closing and reopening the browser window?

We save all settings, toggles and input content on local storage, window.localStorage.

Are there any guarantees about this web application?

While we took utmost care to ensure there are no bugs, we can't guarantee anything: correctness, availability or whatever.

I want to report a bug, what do I do?

If it's an issue with this website, email roy@codsen.com.

If it's an API problem (calculations are wrong), ideally, raise an issue directly on html-crush issues page on our monorepo at GitLab.

Why is the html-crush library not on GitHub?

Because GitHub sold us out to Microsoft and we moved out.

Who is the owner of this website?

Codsen Ltd.