HTML Pack

Shrinks an HTML page into a smaller HTML page that still opens in any browser, and unpacks a packed page back to the exact original bytes.

Drop HTML files here

Plain pages get packed. Pages packed by this tool get unpacked. Add a page together with its CSS, scripts and images, or a whole folder, to fold everything into one file.

HTML source

File name

Encoding inside the file Base-122 About +14% over the compressed data. UTF-8 with a byte-order mark, so it opens correctly from disk or from any web server. Best default. Raw bytes About +1–2%. Smallest file. The page is saved as windows-1252, so a server that forces UTF-8 will stop it from opening, and editors must not re-save it. Base64 About +33%. Plain ASCII that survives e-mail, copy and paste, and any text editor.

Compression

Fast Normal Max Ultra

Auto CM LZMA Deflate

Inline local files When a page arrives together with its CSS, scripts, images or fonts (picked together, or as a folder), they are embedded so the result is one self-contained file. Keep title and link-preview tags visible Copies the page’s title, description, Open Graph and Twitter tags, canonical link and icons outside the compressed data, so search snippets and chat link previews still show them. The loader removes the copies before the page is rebuilt. Minify HTML, CSS and JavaScript Removes comments and indentation before compressing. Every rewritten script must re-tokenize identically and pass a parse check, or it is left as written. Unpacking returns the minified page.

Files

Include the folder’s other files

No files yet. Choose or drop an .html file to pack it.

How the packed file works

The page is compressed with one of three methods. Context mixing predicts each bit from eight blended models (orders 0–6, words, a sparse context and a long-match model, mixed by two learned mixers and refined by an adaptive probability map); it is usually 10–17% smaller than xz -9e on HTML and JavaScript but unpacks at a few hundred KB per second. LZMA (the 7-Zip and xz method) lands within about 1% of xz -9e at Ultra and unpacks almost instantly. Deflate (the gzip method) is the fallback. The context-mixing model uses integer arithmetic only, so every browser engine reproduces its predictions exactly. The data is stored in an HTML comment, and followed by a 2 KB script that decompresses it and writes it into the document with document.write while the browser is still parsing. The original therefore goes through the browser’s normal parser: its scripts run in order, DOMContentLoaded and load fire, the doctype and quirks mode are kept, and attributes on <html> and <body> carry over. The loader removes its own nodes before writing, so the finished DOM matches the original.

Runs in every current browser on desktop, tablet and phone, from disk or a server. All three decoders are plain ES5 and need no DecompressionStream. Every method and encoding was tested in all three browser engines: Chromium (Chrome, Edge, Opera, Brave, Android), Firefox (Gecko) and WebKitGTK (the engine inside Safari and every iOS browser), from disk and over HTTP with conflicting charset headers. Files packed in one engine unpack identically in the others, including context mixing, whose predictor uses integer arithmetic only.
With Inline local files on, stylesheets (including @import and url()), scripts, images, srcset, icons, fonts and media that the page references by relative path are embedded as inline code or data: URLs. Unpacking then returns the inlined single-file page. ES module import statements and fetch() calls inside scripts are not rewritten.
Relative links, images and scripts resolve exactly as before, because the page keeps its own address.
Unpacking restores the original file byte for byte, checked with a CRC-32 stored in the file. It runs the packed file’s own embedded decoder inside an isolated sandbox (an opaque-origin iframe with a stand-in document), so files made by any version of HTML Pack unpack exactly, and a crafted file cannot reach this page. If the sandbox is unavailable, the built-in decoders are used. Every packed file is also unpacked and compared before it is offered for download.
Embedded base64 data (images, fonts, WebAssembly, audio, 3D model buffers in data: URLs or strings) is decoded to raw bytes before compression and re-encoded by the loader before the page is parsed. Only long, canonical runs that re-encode to exactly the same text are touched. Base64 hides byte structure from the compressor; unwrapping it made an embedded TrueType font 21–28% smaller and a 3D mesh buffer 35–55% smaller, while already-compressed PNG and JPEG gain a few percent.
Pages under about 3 KB get bigger, because the loader costs about 2.3 KB. The tool marks those.
Raw-bytes mode sets the document encoding to windows-1252. Non-ASCII text in the page is unaffected, but external scripts or stylesheets with non-ASCII content and no declared charset would then be read as windows-1252, and form submissions use it too. Base-122 and Base64 keep UTF-8.
Minify uses a full JavaScript tokenizer (strings, template literals, regular expressions, ASI-preserving line breaks). It was checked against 637 real-world scripts with zero syntax-tree differences. Scripts of other types (JSON excepted), such as shaders or templates, are never touched, and module scripts are left as written. HTML indentation is collapsed only when no CSS on the page uses white-space: pre.
Choosing a folder switches to site mode: packed pages keep their original names, so links between pages keep working, and Download site as .zip rebuilds the folder tree with every packed page in place and, unless you untick it, the folder’s other files beside them. Zip entries are deflated where that helps.
A page with a Content-Security-Policy that forbids inline scripts cannot unpack itself.