HTML5 Banner & Asset Compressor
Reduce PNG and JPEG weight inside HTML5 banner ZIPs while keeping filenames, paths and animation code intact. Everything runs privately in your browser.
Reduce PNG and JPEG weight inside HTML5 banner ZIPs while keeping filenames, paths and animation code intact. Everything runs privately in your browser.
Google Ads enforces a strict 600 KB total payload limit for all assets within an uploaded HTML5 ZIP package, including HTML, JavaScript, CSS, and images. Compressing raster images directly inside the ZIP solves this issue without altering your code structure.
No. The compressor preserves exact relative file paths, filenames, and image formats inside the ZIP archive, so clickTag code and the references in Adobe Animate, Google Web Designer, or custom JavaScript manifests keep working. At 100% scale every image keeps its pixel dimensions. When you downscale, images that look like sprite sheets or that are drawn at their natural size stay at full size, and the summary lists every file that was resized so you can preview the banner before you ship it.
Never. Every file operation runs locally in browser memory via HTML5 Canvas and JSZip APIs. Unreleased client ad creatives never leave your computer, preserving client confidentiality and strict agency non disclosure agreements.
Google Ads accepts an animated GIF image ad only when three things are true: the file is 150 KB or smaller, the animation stops within 30 seconds, and it plays slower than 5 frames per second. A GIF exported straight from a design tool usually breaks all three at once, because it loops forever, runs at 20 or 25 frames per second and carries a full palette in every frame.
The optimizer fixes each rule without touching the pixel dimensions, so a 300×250 ad stays exactly 300×250. Frames shorter than 200 ms are merged into the frame they belong to, and their time is added to it, so the loop lasts exactly as long as before. The number of plays is set so the total stays within 30 seconds, and a single loop longer than 30 seconds is cut so it ends on your final frame, where the call to action usually sits.
To reach 150 KB it rebuilds the colour table with a median cut quantizer, stores only the rectangle that changed from one frame to the next, and writes a fresh LZW stream. It tries 256, 128, 64 and then 32 colours, with and without dithering, and only then merges more frames. The first setting that fits is the one you get, and the report shows which one it was. If nothing fits, it says so and gives you the smallest version.
Everything runs inside your browser in a background worker. The GIF never leaves your machine. When you are done, load the file into the HTML5 Banner Validator for a final check, and read the guide to animated GIF restrictions and loop caps for the rules on other networks.
The usual reasons are a file over 150 KB, a loop that never stops, or frames shorter than 200 ms, which is 5 frames per second or faster. The optimizer shows a pass or fail line for each rule, before and after.
No. A dropped frame gives its delay to the frame that stays, so one loop lasts exactly as long as the original. Motion looks less fluid, but the timing of every scene is kept.
As many times as fit in 30 seconds. A 3 second loop can play 10 times. The GIF stores this as a loop count of 9, because the first play is not counted. The optimizer writes that number for you.
Yes. After a ZIP is compressed, any GIFs it contains are listed with an Optimize GIFs in Place button. Each file keeps its name and path, so the banner code still finds it.