Every Tool You Need Before Deploying a Website to Production
A pre-deploy checklist with free browser tools: minify CSS, HTML, and JS, compress images to WebP, optimize SVGs, validate configs, and verify file integrity.
The Pre-Deploy Checklist
You have built the feature. Tests pass on your branch. Code review is approved. The pull request is green. Before you merge and ship to production, there is a mechanical checklist that catches the bottlenecks your CI pipeline does not always cover.
Oversized images that load in four seconds on a fiber connection but 15 seconds on 4G. Unminified CSS and JavaScript that add 80 KB of whitespace and comments to every page load. SVGs bloated with Illustrator metadata. A JSON config with a trailing comma that works fine locally but breaks the production build because your local parser is more forgiving.
Each step in this checklist links to a free browser tool that processes data locally. No uploads. No node_modules. No build pipeline configuration. Open the tab, run the tool, and move on.
1. Minify CSS
Your development stylesheet has comments explaining each section, blank lines between rule sets, indentation that makes the cascade scannable, and verbose hex values like #ffffff. In production, every one of those bytes is dead weight that the browser must download, parse, and discard.
The CSS Minifier strips comments, whitespace, trailing semicolons, and shortens hex colors where safe. A typical unminified stylesheet drops 30 to 40 percent in file size. On a 50 KB stylesheet, that recovers roughly 17 KB per request. Across a page with three stylesheets (reset, framework, custom), the savings compound.
What the minifier does step by step: it removes all comments, collapses multiple spaces and newlines into single spaces, deletes the last semicolon before a closing brace, shortens #ffffff to #fff (and equivalent patterns), removes leading zeros from decimal values (0.5em to .5em), and strips units from zero values (0px to 0).
If you later need to debug a production stylesheet, the CSS Beautifier reverses the process. It restores indentation, newlines, and spacing for readability. Do not serve beautified CSS to users. Use it for inspection only.
Deployment strategy: keep your source CSS formatted and commented. Add the minifier as the final step before uploading assets. Some frameworks and CDNs minify automatically. Verify that yours does before you skip this step.
2. Minify JavaScript
Your JavaScript bundle ships with comments, descriptive variable names, whitespace, and sometimes dead code paths that your tree shaker missed. The JS/TS Minifier strips comments, shortens local identifiers through mangling, and removes unreachable code and console statements.
A 200 KB unminified bundle can drop to roughly 60 KB minified. After gzip or brotli compression at the CDN level, that 60 KB becomes roughly 18 KB over the wire. The difference between 200 KB and 18 KB is the difference between a page that loads in 1.5 seconds and one that loads in 6 seconds on a slow connection.
Important: the minifier accepts compiled JavaScript. If you write TypeScript, compile it to JavaScript first (either through tsc, esbuild, or your bundler). Do not paste TypeScript source directly into the minifier. It does not strip type annotations and will produce invalid output.
What mangling does: the minifier renames local variables from userAuthenticationToken to a, calculateCartTotal to b, and so on. Short variable names save bytes. Function names, object properties, and exported symbols are preserved because renaming them would break references. The mangling is safe as long as you feed it compiled output where the module boundary is already resolved.
3. Minify HTML
HTML minification is the last optimization after CSS and JS, but it is still worth doing. Your HTML template contains whitespace between tags, HTML comments left over from development, and boolean attributes written in long form.
The HTML Minifier strips whitespace between tags (preserving whitespace inside <pre>, <code>, and <textarea> elements), removes HTML comments, shortens boolean attributes (checked="checked" to checked), and removes optional closing tags where the spec allows.
A 28 KB HTML page can drop to roughly 18 KB. On a content site with 50 pages, that is 500 KB saved across the site.
Deployment strategy: do not write minified HTML by hand. Keep your source templates formatted and readable with the HTML Formatter. Minify as a build step, not as a source convention. If you use a static site generator (Astro, Hugo, Eleventy, Next.js static export), check whether it already minifies HTML output. Many do. If yours does not, add minification as a post-build step.
4. Convert Images to WebP
PNG and JPEG images account for roughly 45 percent of the average web page's total weight, according to the HTTP Archive. Converting those images to WebP saves 25 to 35 percent on every file without visible quality loss.
Use the PNG to WebP Converter for raster graphics: logos, icons, illustrations, screenshots. Use the Image Converter for JPEG photographs that you want to convert to WebP while keeping the smaller file size.
How to serve WebP safely: because roughly 3 percent of global browser traffic still comes from browsers that do not support WebP, serve the WebP version with a <picture> element and a PNG or JPEG fallback:
<picture>
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" alt="Hero image">
</picture>
The browser that supports WebP requests the .webp file. The browser that does not falls back to the .jpg. Both see the image. Neither waits for a format they cannot decode.
When not to use WebP: Safari added WebP support in version 14 (released 2020). If your analytics show a meaningful share of users on older Safari versions, keep the fallback. For email templates, stick with JPEG and PNG. Email clients do not support <picture> and many strip WebP images.
5. Compress Images
Before converting to WebP, compress your source images. A photograph straight from a camera or stock photo site is often 3 to 8 MB at quality 100. That is 10 to 20 times larger than it needs to be for web display.
The Image Compressor adjusts JPEG quality with a live side-by-side preview. Drag the quality slider and watch the original and compressed versions update in real time. Quality 85 is the sweet spot for web photos: 60 to 80 percent file size reduction with no visible quality loss at screen resolution.
Concrete numbers: a 4 MB stock photo at quality 100 drops to roughly 800 KB at quality 85. Converted to WebP, it drops further to roughly 500 KB. Served at the actual display dimensions (see step 6), it drops to 120 KB. From 4,000 KB to 120 KB with no visible difference at screen resolution. That is a 97 percent reduction.
6. Resize Images to Display Dimensions
A 4000 by 3000 pixel photograph displayed in an 800 by 600 pixel container wastes bandwidth on every request. The browser downloads the full image, scales it down in memory, and discards the unused pixels.
The Image Resizer scales images to exact pixel dimensions before you upload them. Measure your layout's maximum display width for the image slot and set the width to double that for retina screens. If the slot is 800 pixels wide, resize to 1600 pixels. For a thumbnail grid at 300 pixels, resize to 600 pixels.
Concrete example: a blog post hero image displayed at 1200 by 630 pixels. The original photo is 5472 by 3648 pixels (20 megapixels). Resizing to 2400 by 1260 (2x for retina) drops the file from 6 MB to roughly 400 KB before compression. Compress at quality 85 and convert to WebP: final file size around 200 KB. The image looks identical on screen.
Resize first, compress second, convert to WebP third. Resizing after compression re-compresses the image and can introduce double-compression artifacts.
7. Optimize SVGs
Vector graphics exported from Illustrator, Figma, or Sketch carry editor metadata, comments, XML namespaces you are not using, unnecessary precision on path data (12.345678 only needs 12.3 for screen display), and sometimes hidden layers.
The SVG Optimizer strips the bloat. A 15 KB SVG exported from Illustrator typically shrinks to 2 to 4 KB with identical rendering output. The optimization is lossless for display purposes.
What the optimizer removes: XML comments, editor-specific metadata tags, unused namespace declarations, unnecessary id attributes on elements that are not referenced by CSS or JavaScript, and excessive decimal precision on numeric attributes.
If you use SVGs inline in HTML (as opposed to <img> tags), optimization matters even more. The SVG markup is part of your HTML payload and contributes to every page's download weight.
8. Generate Favicons and Social Preview Images
Favicons and Open Graph images are the two asset types most often forgotten until the site is already live and someone shares a link on Twitter or Slack and sees a blank preview.
The Image Converter and Image Resizer produce correctly sized assets from a single source image. The standard sizes are:
- Favicon: 32 by 32 pixels for browser tabs, 180 by 180 for Apple Touch Icon
- Open Graph image: 1200 by 630 pixels for Facebook, Twitter, LinkedIn, Slack, Discord
- Twitter card: same 1200 by 630, with a 2:1 aspect ratio
If your source is a vector logo, export it to PNG through the SVG to PNG Converter at the target resolution. Set the output width to 1200 pixels for the Open Graph image and 180 for the Apple Touch Icon.
Verification step: after deploying, test your Open Graph image with Facebook's Sharing Debugger and Twitter's Card Validator. Both are free tools that show you exactly how your link preview will appear before anyone shares it.
9. Validate Config Files Before Deploy
A trailing comma in a JSON config file. A YAML key misindented by one space. A TOML section header missing its brackets. Each of these breaks the production build. Your local environment might tolerate them. The production environment will not.
Run every config file through the corresponding validator before deploying:
- JSON Validator for JSON configs, package.json, manifest files
- YAML Validator for Kubernetes manifests, Docker Compose files, CI pipeline definitions, Ansible playbooks
A validation pass in the browser takes five seconds. A failed production deploy because of a syntax error takes five minutes to roll back, plus the time your site was down.
Concrete scenario: your CI pipeline builds the site successfully but the deploy step fails with a YAML parse error. You check the YAML Validator and it points to line 34: a value indented with a tab instead of spaces. Your local editor displayed the tab as spaces. The production YAML parser did not. You caught it before rolling back.
10. Verify File Integrity After Build
After your build produces the final assets, hash them. After deployment, hash the served files and compare. If the hashes match, the files were not corrupted or modified in transit.
The Hash Calculator computes SHA-256 digests from files. Feed it your built CSS, JS, and image files. Store the hashes. After deployment, download each file from the live URL and hash it again. Matching hashes mean bit-for-bit identical files.
Concrete scenario: you deploy a new version of your main JavaScript bundle. A user reports that the site is broken. You hash the local build output and the deployed file. The hashes differ. The CDN served a stale cached version of the bundle. You trigger a cache invalidation and the site recovers instantly. Without the hash comparison, you would have spent an hour debugging JavaScript that was not actually the version you deployed.
The Local Processing Guarantee
Every tool in this checklist processes files and data in your browser's JavaScript runtime. The image compressor uses the Canvas API to re-encode JPEGs at your chosen quality setting. The SVG optimizer parses and reserializes the SVG DOM. The hash calculator uses the Web Crypto API. The minifiers use string manipulation in JavaScript.
No file you upload for compression, conversion, or hashing leaves your machine. This matters when the files contain proprietary designs, unreleased features, or client assets covered by an NDA.
Run the checklist: every tool listed processes data locally in your browser. No files leave your machine. Browse the full tools directory to find additional tools for your specific stack. Bookmark the ones you need before every deploy.