Free · Fast · Privacy-first

Minify HTML, JavaScript, and CSS Together

Fully optimised production performance requires minifying all three static asset types that make up a web page.

⚡

Separate tools for HTML, CSS, and JS

🔒

All free and browser-based

✨

Complete minification workflow

⚡

No installation or build tools required

Cost: Free forever
Sign-up: Not required
Processing: In your browser
Privacy: Files stay local

FreeNo signupWhite-label

Add this HTML Minify to your website

Drop the HTML Minify into any page — blog post, product docs, intranet, school portal — with a single line of HTML. Your visitors get the full tool, processed entirely in their browser. No backend, no uploads, no signup.

Files stay 100% in the visitor's browser
Responsive — adapts to any container width
Free forever, no API key needed

Embed code

<iframe
  src="https://www.fixtools.io/html/html-minify?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="HTML Minify by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

<iframe
  src="https://www.fixtools.io/html/html-minify?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="HTML Minify by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.

Full-Stack Static Asset Minification: HTML, CSS, and JavaScript Together

A web page is built from three file types, each contributing independently to the total byte payload the browser must download before the page is fully interactive. HTML defines the document structure and is downloaded first, blocking rendering until enough of it is parsed to build the initial DOM. CSS is render-blocking: the browser will not paint the page until all stylesheet content is downloaded and parsed into the CSSOM. JavaScript that is not deferred or async-loaded blocks the HTML parser, preventing DOM construction and rendering until each script is downloaded and executed. Unminified, a typical marketing page might carry 60KB of HTML, 80KB of CSS, and 150KB of JavaScript. Minifying all three reduces this to approximately 48KB HTML, 60KB CSS, and 120KB JavaScript. The combined 62KB saving, before server compression, represents a 21 percent reduction in total payload. Under Brotli or gzip compression, the savings compound further. The browser starts rendering sooner, the LCP element loads faster, and interactive time is reached earlier.

The correct order for minifying multiple file types matters when those files reference each other. CSS and JavaScript should be minified before HTML for two reasons. First, inline script and style blocks in HTML that you want to compact must be replaced with their minified versions before the HTML minification pass, otherwise the HTML minifier processes formatted CSS and JavaScript inside those blocks without being able to minify their content. Second, if you use content-hash-based filenames for external CSS and JS files, those hashes are computed from the file content after minification. The final HTML file references these hashed filenames in its link and script tags, so the HTML must be assembled and minified after the CSS and JS filenames are known. Following the order CSS, then JavaScript, then HTML ensures these dependencies are resolved correctly.

For ongoing production projects, automating the entire three-file minification sequence in a build pipeline is more practical than manual minification on every deployment. Webpack handles all three with HtmlWebpackPlugin for HTML, css-minimizer-webpack-plugin for CSS, and the built-in Terser integration for JavaScript. Vite applies CSS and JavaScript minification automatically in production builds and optionally applies HTML minification through its plugin ecosystem. For projects without a build tool, and for one-off minification tasks or spot-checks, use the FixTools CSS Minifier, JavaScript Minifier, and HTML Minifier in sequence to achieve the same quality output manually.

Template engines complicate the joint minification story in a specific way that is worth understanding before configuring a pipeline. When Jinja2, Liquid, Twig, or Handlebars renders a page, it interpolates variables into a base template and produces a final HTML string that contains the rendered values along with any whitespace from the template structure. CSS classes and JavaScript hooks referenced inside template tags are stable strings, but the surrounding markup carries the indentation of the template file itself. Running minification on the template source before rendering can corrupt template syntax when whitespace surrounds significant tags. Running minification on the rendered output after every render is functionally safe but expensive at scale. The middle path is to render once during the build, minify the rendered HTML alongside the bundled CSS and JavaScript, and ship the trio together. For sites that personalise per request, minify the static template scaffolding at build time and inject only the personalised tokens at request time, which preserves most of the saving without per-request minification cost.

web.dev: Fast load times web.dev: JavaScript performance

How to use this tool

💡

Start with HTML Minify, then CSS Minifier, then JS Minifier. Together they cover every static asset type for maximum production performance.

How It Works

Step-by-step guide to minify html, javascript, and css together:

1
Minify CSS first
Open the FixTools CSS Minifier and paste each of your CSS files in turn, clicking Minify for each. Copy the minified output and save it as your production CSS. Record the original and minified sizes. If you have inline styles in your HTML, collect the minified versions of these CSS blocks too for use in the next step.
2
Minify JavaScript
Open the FixTools JavaScript Minifier or an equivalent tool such as Terser Online and paste each of your JavaScript files. Copy the minified output as your production JavaScript. If you have inline script blocks in your HTML, collect the minified versions for those too.
3
Minify HTML
Open the FixTools HTML Minifier, paste your HTML, and if it contains inline CSS or JavaScript blocks, replace them with the minified versions you produced in the previous two steps before clicking Minify. This ensures that inline blocks are also minimised in the final output.
4
Deploy all minified files
Deploy the minified HTML, CSS, and JavaScript files together as your production build. Confirm that CSS and JavaScript filenames referenced in the HTML match the filenames of the minified CSS and JavaScript files you are deploying. Run a final PageSpeed Insights audit to confirm the combined improvement across all three file types.

Real-world examples

Common situations where this approach makes a real difference:

Full static site optimisation before launch

Before launching a static marketing site with 12 HTML pages, 3 CSS files, and 5 JavaScript files, the developer manually minifies all assets using the FixTools suite. The CSS files reduce from a combined 78KB to 61KB. The JavaScript files reduce from 145KB to 112KB. The HTML pages average 14 percent reduction per file. The total asset size before server compression drops from 279KB to 217KB, a 62KB saving that translates to a 200ms faster load time on a standard broadband connection and over 400ms on a throttled 4G mobile connection.

Performance sprint to improve Core Web Vitals

A product team runs a focused two-day performance sprint targeting LCP improvement on their top three landing pages. They systematically minify all three asset types: HTML saves an average of 14KB per page, CSS saves 22KB across shared stylesheets, and JavaScript saves 45KB from the main bundle after switching to a newer Terser configuration. The combined 81KB reduction in total payload improves LCP from an average of 3.8 seconds to 2.9 seconds across the three pages, moving all three from "Needs Improvement" to "Good" in their Core Web Vitals assessment.

When to use this guide

Use this as a complete performance optimisation workflow guide for preparing all production static files, HTML, CSS, and JS, before deployment.

Pro tips

Get better results with these expert suggestions:

Calculate total savings as a percentage of page weight

After minifying HTML, CSS, and JavaScript, add up the original sizes of all three file types and the minified sizes, then calculate the percentage reduction as a single figure. For example, if the combined original size is 290KB and the combined minified size is 222KB, the total saving is 23 percent. This single-number metric is clear, meaningful, and directly communicable to stakeholders who want to understand the impact of the optimisation sprint without reviewing each file type separately.

Check for duplicate code across files

While reviewing files for minification, look for utility functions that appear in multiple JavaScript files, or CSS utility classes and reset rules that are duplicated across multiple stylesheets. Minification reduces the byte cost of duplicate code proportionally but does not eliminate the duplication itself. Identifying and removing duplicate code before minification produces larger and more permanent savings than minification of duplicated content, and reduces the complexity of the codebase as an additional benefit.

Use source maps for production debugging

When deploying minified CSS and JavaScript for production, generate source maps alongside the minified files. Source maps allow browser DevTools to display the original formatted, named source code when you inspect styles or debug JavaScript in a production session. Without source maps, minified variable names and collapsed CSS rules make production debugging extremely difficult. HTML source maps are less commonly used but are available through some build tools. The source map files are large and should not be served to regular users but should be available to your internal DevTools.

Set up a size budget in your CI/CD pipeline

Define maximum acceptable file sizes for your HTML, CSS, and JavaScript bundles and enforce these limits as a failing check in your CI/CD pipeline using a tool like bundlesize or the built-in budget features in Angular CLI and Next.js. When a build exceeds the budget for any file type, the pipeline fails and alerts the developer who introduced the change. This prevents the gradual size creep that can quietly undo months of optimisation work as new dependencies, components, and features are added to the project over time.

Minify in this order: CSS, JS, HTML

Minify CSS and JS first (they may be referenced in HTML). Then minify the HTML. This order ensures inline scripts and styles are also minified if present.

Track total size reduction across all file types

After minifying HTML, CSS, and JS, compare the total before and after sizes across all files. The combined reduction gives a realistic picture of performance improvement.

Automate with a build tool for ongoing projects

For projects with regular deployments, automate HTML, CSS, and JS minification in a build pipeline (Webpack, Vite, Parcel). Use FixTools for one-off tasks or during initial setup.

FAQ

Frequently asked questions

Minify CSS first, then JavaScript, then HTML. This ordering matters because CSS and JavaScript minification must happen before HTML when your HTML contains inline script or style blocks that you want to compact, or when you use content-hash-based filenames for external CSS and JS files. The CSS and JS filenames are determined by their minified content hashes, and the HTML must reference these correct final filenames, so HTML must be assembled and minified last in the sequence.

Build tools like Webpack and Vite handle all three file types automatically in a single production build command. Webpack uses HtmlWebpackPlugin for HTML minification, css-minimizer-webpack-plugin for CSS, and the built-in Terser plugin for JavaScript. Vite handles CSS and JS minification natively and supports HTML minification via the vite-plugin-html plugin. For manual minification, FixTools provides separate tools for each file type that can be used in sequence to achieve the same result without a build environment.

For a typical page with developer-formatted assets, minifying HTML, CSS, and JavaScript together typically reduces total source file payload by 15 to 25 percent compared to the formatted originals. JavaScript usually provides the largest absolute saving because it tends to be the largest file type and because variable name mangling in addition to whitespace removal compounds the size reduction. With server-side gzip or Brotli compression applied on top, the combined reduction from unminified source to compressed transfer is typically 70 to 80 percent of the original uncompressed, unminified size.

Do not re-minify third-party scripts and styles loaded from external CDNs, such as analytics libraries, chat widgets, payment SDKs, and advertising tags. These are already minified by their vendors and served from vendor-controlled CDNs optimised for delivery. Re-minifying them would require downloading, modifying, and self-hosting them, which removes the CDN delivery benefit, breaks vendor update flows, and may violate terms of service. Focus all minification effort on your own first-party HTML, CSS, and JavaScript files.

HTML and CSS minification carry minimal risk when applied correctly. HTML minification removes whitespace and optional tags defined as safe by the HTML5 specification. CSS minification removes whitespace and redundant declarations. JavaScript minification carries more risk because it evaluates code rather than just parsing markup. Variable name mangling can break code that uses eval, accesses property names as strings, or relies on Function.name. Use a well-tested tool such as Terser with appropriate mangle configuration and test your JavaScript thoroughly after the first minification pass before deploying to production.

Open browser DevTools and navigate to the Network tab. Reload the page and let all requests complete. Click the Size column header to sort resources by size from largest to smallest. JavaScript bundles are typically the largest single file type, followed by CSS stylesheets, then HTML. For a more detailed analysis, run WebPageTest and review the "Bytes by Content Type" chart, which breaks down the total page weight by file type as a percentage of the total, showing exactly where the largest optimisation opportunities are.

Yes, across all three Core Web Vitals dimensions. Smaller HTML reduces TTFB and accelerates the initial DOM construction, improving LCP and FCP. Smaller CSS reduces the time spent building the CSSOM, which unblocks rendering earlier and improves FCP and LCP. Smaller JavaScript reduces main thread parse and execution time, reducing blocking periods that delay interactive response and improving INP and TTI. The combined effect of minifying all three file types addresses performance bottlenecks across all phases of the page loading lifecycle, producing improvements in every Core Web Vitals metric.

React hydration mismatches typically appear when the markup the server rendered does not match the markup the client expects to find. Aggressive HTML minification can introduce mismatch in two specific ways: optional closing tag removal in lists and tables that the browser parser handles differently than the React reconciler, and whitespace text node removal that shifts child indices in components that read childNodes directly. The fix is to configure your HTML minifier to keep optional closing tags intact in any markup destined for hydration, leave script blocks containing serialised React state completely untouched, and refactor any component code that reads childNodes to read element.children instead. Re-deploy after the configuration adjustment and hydration warnings should disappear from the console.

Yes, but with different magnitudes depending on the framework. Next.js production builds already minify HTML, CSS, and JavaScript by default, so the additional saving from external tools is small, typically two to four percent on each file type. Vue with Vite applies the same defaults, and Vue CLI does similarly with webpack. The right role for FixTools in a framework project is for files that live outside the framework runtime: static landing pages in the public folder, email templates, marketing pages built as standalone HTML, and any prerendered files destined for a CDN that bypasses the framework. For those files, manual minification through the FixTools three-tool sequence captures the full saving and stacks additively with whatever optimisation the framework applies internally to its own outputs.