HTML5 Ad File Size Limits: Why Your ZIP Size Isn't the Whole Story

The three limits are not interchangeable

The table below describes the current official rules relevant to these examples. “Google Ads” here means the standard uploaded-display route, not every HTML5-capable Google Ads campaign type.

Google publishes the 600 KB and 40-file requirements in its uploaded display ad specifications and repeats related package checks in its uploaded-ad error guide. DV360’s HTML5 display guidelines separate the 5 MB browser-download maximum from the ZIP itself, while its HTML5 creative upload guide limits a package to 100 files. Ad Manager’s HTML5 trafficking guide explicitly applies 1 MB to the bundle or the extracted total.

Original diagram: one “file size” question becomes four measurements before an operator can make a route-specific decision.

Measure four layers, not one number

1. Compressed ZIP bytes

This is the archive size shown by your operating system and the file sent to an upload interface. It is easy to record and easy to misunderstand. ZIP compression can reduce repetitive text dramatically while barely shrinking an already compressed JPEG, PNG, MP4, WOFF2, or audio file.

For Google Ads uploaded display, the final HTML5 ZIP is the submitted artifact, so the 600 KB requirement is directly relevant to this number. The cited standard-upload specifications do not publish a second extracted-total ceiling. That does not make extracted size useless; it means the documented acceptance gate is different from Ad Manager’s gate.

Record exact bytes rather than writing “0.6 MB” in a handoff. The cited Google pages use KB and MB labels but do not define decimal versus binary units on those entries. A package comfortably below the limit avoids turning that ambiguity into a last-minute argument.

2. Extracted file bytes

Unzip the package and add the size of every file. This exposes content that compression concealed and catches the Ad Manager failure mode directly.

Our intentionally invalid package contains a referenced SVG with repetitive source padding. The archive is only 3,152 bytes, but the SVG expands to 1,250,356 bytes and the complete extracted package reaches 1,252,904 bytes. The art still renders. The failure is not visual; it is the extracted-size rule.

This is why “the ZIP is under 1 MB” is an incomplete Ad Manager check. The official requirement is that the HTML5 bundle or the total size of the extracted files cannot exceed 1 MB. A release checklist needs both measurements.

3. Resources the browser actually loads

A ZIP is a delivery container. A browser runs documents and requests resources. For a self-contained creative, the extracted local inventory is a useful starting point, but it is not automatically identical to a served transfer measurement. Server compression, caching, redirects, allowed external libraries, and runtime requests can change what crosses the network.

DV360 makes this distinction operationally important: its guidelines state that the browser may download no more than 5 MB of total creative files and warn that publishers can impose a smaller limit. The same page also caps HTTP calls at 100. A 29 KB ZIP does not grant permission to fetch an unbounded image sequence, font family, analytics bundle, or remote video after launch.

Measure two things for a DV360 release:

1. The final ZIP and its local contents, so packaging mistakes are visible.
2. A network trace in the intended serving or preview environment, so actual requests and transferred resources are visible.

The downloadable DV360 example in this article has no remote assets. Its 42,797 extracted bytes therefore provide a clean local inventory, but our local Chromium check was not a DV360 serving-transfer measurement.

4. Route rules that bytes cannot satisfy

A package can be small and still be rejected or malfunction. Common gates include file count, primary-document structure, dimensions metadata, permitted file types, click behavior, SSL compatibility, animation duration, nested archives, remote-resource restrictions, and account eligibility.

Examples from the official documentation make the point:

• Google Ads uploaded display permits no more than 40 files and requires a primary HTML file with valid dimensions metadata for hand-coded uploads.
• DV360 permits up to 100 files, requires a detectable exit or click tag, and says the creative must load in an iframe.
• Ad Manager detects fixed dimensions and a standard click tag, serves HTML5 creatives through SafeFrame, and requires SSL-compatible assets.
• Ad Manager’s limitations page says inline SVG tags in the HTML are unsupported, even though standalone SVG files are allowed. That is a markup rule, not a size rule.

A “green” size cell should therefore be named size pass, not platform pass.

Google Ads: use the standard uploaded-display contract

For a standard uploaded HTML5 display ad, Google accepts a ZIP containing HTML plus supported resources such as CSS, JavaScript, GIF, PNG, JPG/JPEG, and SVG. Its specifications set the supported file size at 600 KB or smaller and the ZIP at no more than 40 files. Hand-coded packages need a doctype, HTML and body elements, a primary HTML file, meta name="ad.size", and valid relative paths for local resources. Google also applies feature restrictions and requires the account to be eligible to use HTML5 ads.

The original Google Ads example package is deliberately simple:

• ZIP size: 28,917 bytes
• Extracted total: 42,591 bytes
• Files: 5
• Largest file: hero.jpg, 38,911 bytes
• Root document: index.html
• Dimensions metadata: width=300,height=250

Its source contains no custom exit script. The visual CTA is not proof of a click implementation; the teaching package leaves final click-through handling to the host workflow. That choice keeps this example focused on packaging rather than implying that one hand-coded click pattern is correct for every Google Ads build path.

The package is comfortably within the documented size and file-count gates, all referenced local files resolve, and it rendered at 300 × 250 in our local test. It was not uploaded, so the defensible status is: locally preflighted, not platform-accepted.

Do not borrow 600 KB for App campaigns

Google Ads also supports HTML5/playable assets for App campaigns, but that is a separate contract. The App campaign HTML5 overview states a maximum ZIP size of 5 MB and up to 512 files. A current App campaign troubleshooting page says interstitial assets at 320 × 480 or 480 × 320 can be up to 5.2 MB.

Those two official pages currently present different written maxima. Do not silently convert them into one invented “true” number. A conservative production policy is to plan to the lower 5 MB statement, retain meaningful headroom, and verify the actual campaign upload route before final delivery. That is an operational choice, not a new Google rule.

DV360: the ZIP is not the serving budget

DV360 creates the most obvious separation between archive size and runtime load. Its documentation says there is no size limit for the ZIP file, but a ZIP may contain no more than 100 files. Separately, the browser-download maximum is 5 MB for the creative, and an individual publisher may require a smaller creative.

The original DV360 example package measures:

• ZIP size: 29,009 bytes
• Extracted total: 42,797 bytes
• Files: 5
• Largest file: hero.jpg, 38,911 bytes
• Root document: index.html
• Readable default clickTag: https://example.com/

The click test instrumented window.open locally and captured the expected teaching URL. That proves the packaged click expression invoked the default value in our preview. It does not prove DV360 recognition, macro substitution, landing-page policy compliance, exchange acceptance, or publisher acceptance.

A reliable DV360 handoff therefore needs two budgets. The package budget controls file count, structure, and what you upload. The runtime budget controls browser-loaded resources and requests. Treating “no ZIP size limit” as “no creative size limit” erases the second budget and invites late failures.

The same distinction helps optimization. Deleting 200 KB of unreferenced source makes the ZIP cleaner but may not change runtime at all. Removing a 900 KB runtime-loaded library changes both package and browser load. Moving that library to a remote URL may shrink the ZIP while leaving the browser budget unchanged—or making the package noncompliant with a route’s external-resource rules. Optimize the measured layer that is actually failing.

Ad Manager: test the archive and the opened package

Ad Manager’s wording closes the compression loophole: an HTML5 bundle or the total size of its extracted files cannot exceed 1 MB. The creative also needs fixed dimensions, at least one standard click tag, SSL-compatible resources, and valid package structure. Google says Ad Manager HTML5 creatives always serve in a SafeFrame, so behavior that depends on escaping or controlling the parent page needs explicit testing rather than assumption.

The original valid Ad Manager package measures:

• ZIP size: 29,007 bytes
• Extracted total: 42,789 bytes
• Files: 5
• Dimensions: 300 × 250
• Readable default clickTag: https://example.com/

The original Ad Manager extracted-size trap measures:

• ZIP size: 3,152 bytes
• Extracted total: 1,252,904 bytes
• Files: 4
• Largest file: trap.svg, 1,250,356 bytes
• Extracted-to-archive ratio: 397.495×

Both render as designed locally. Only the first is within Ad Manager’s documented size condition. The trap is useful precisely because a visual review and a glance at the archive size would both miss the decisive problem.

What the four measured packages prove

These are exact measurements of the files delivered with this article, not rounded estimates.

The complete measurement ledger breaks every archive into individual entries and records SHA-256 hashes. The supplied script reproduces the ZIP and extracted totals:

python HB56_measure_package_v1.py \
  assets/HB56_google_ads_300x250.zip \
  assets/HB56_dv360_300x250.zip \
  assets/HB56_ad_manager_300x250.zip \
  assets/HB56_admanager_trap_300x250.zip

A local measurement utility is intentionally narrower than a platform validator. It can count bytes, files, paths, nested ZIPs, and root HTML documents. It cannot grant account eligibility, emulate Google’s review systems, know a publisher’s private cap, or certify behavior inside every serving environment.

Use a release card instead of “under the limit”

A useful handoff fits on one small record. Fill it from the final archive, not from a design export produced three revisions ago.

That wording prevents a common status inflation. “Ready for upload” means the producer completed a local preflight. “Uploaded” means an account accepted the file. “Approved” means the relevant review completed. “Served” means the creative ran in its intended inventory. Keep those states separate.

A repeatable size preflight

1. Name the route before measuring

Write the product, campaign or creative type, and upload path. “Google HTML5” is too broad. “Google Ads standard uploaded display,” “Google Ads App campaign HTML5,” “DV360 display creative,” and “Ad Manager HTML5 creative” lead to different rule sets.

2. Freeze the actual release ZIP

Do not measure a source folder and assume the resulting archive will match. Packaging can add hidden files, duplicate folders, source maps, editor metadata, or an unnecessary outer directory. Hash the final ZIP so every later result points to the same bytes.

3. Record archive, extraction, and file inventory

Capture exact archive bytes, extracted bytes, file count, largest entries, and compression ratio. Reject nested ZIPs and unsafe paths. Confirm the primary HTML file is where the route expects it and every relative reference resolves inside the package.

4. Inspect runtime loading separately

Use the closest available preview or serving environment and inspect the network panel. Count requests, transferred resources, redirects, remote libraries, fonts, media, and late loads triggered by interaction. A source-folder sum is not a substitute for this step when the platform defines a browser-download budget.

5. Apply structural and behavior rules

Check dimensions metadata, click or exit tags, SSL, file types, filenames, animation duration, audio behavior, storage use, iframe/SafeFrame assumptions, and route-specific restrictions. The official Ad Manager HTML5 guidelines and the corresponding Google Ads and DV360 pages should remain attached to the release ticket because these requirements can change.

6. Use an internal ceiling with headroom

Do not build to the final labeled unit. A team might choose internal ceilings such as 500,000 exact ZIP bytes for a 600 KB Google Ads standard upload, 4,500,000 browser-loaded bytes for a 5 MB DV360 route, or 900,000 bytes for both Ad Manager measurements. Those are example production policies, not platform requirements. Their value is operational: small export changes, metadata, publisher differences, and unit interpretation do not immediately push the release onto an edge.

7. Re-run the final artifact after every optimization

Replacing an image can change both raw and compressed size. Minifying repetitive JavaScript may reduce extracted bytes substantially but change ZIP bytes less dramatically because compression already removed repetition. Converting a PNG to a JPEG may reduce both. Re-measure instead of predicting.

Optimize the failing layer first

When a creative is too large, work in this order:

1. Remove unused files and unreachable variants. This improves archive size, extracted size, file count, and review clarity without changing the intended ad.
2. Right-size dominant media. Resize images to their maximum rendered dimensions; tune quality with side-by-side visual review; remove invisible alpha; shorten or remove media that does not earn its budget.
3. Eliminate duplicated assets. One shared sprite, font subset, or reusable texture is better than copies hidden under different filenames.
4. Audit frameworks and source maps. A tiny animation may not justify a large general-purpose bundle. Production archives should not carry maps, test fixtures, comments archives, or editor caches unless the route truly needs them.
5. Reduce request count as well as bytes. This matters directly in DV360 and improves robustness elsewhere. Do not “fix” a ZIP limit by moving everything to remote URLs without checking whether the route permits those requests and how they count at runtime.
6. Preserve behavior while compressing. Reopen the final archive, render it, exercise meaningful interactions, and inspect the console. A smaller broken ad is not an optimization.

The key is diagnosis. A 41-file Google Ads ZIP needs one fewer file even if it weighs 30 KB. A DV360 creative with a small archive and 6 MB of runtime-loaded media needs a runtime reduction. An Ad Manager archive that expands beyond 1 MB needs an extracted-size reduction even when the ZIP appears tiny.

The decision rule

Never approve an HTML5 ad with the sentence “the ZIP is under the limit.” Approve a named artifact against a named route:

For this exact ZIP and route, the archive size, extracted total, file count, local references, runtime requests, dimensions, click behavior, and route-specific restrictions have been checked; account and publisher validation remain separate states.

That sentence is longer because the real decision is larger. The compressed ZIP matters. It is simply not the whole story.

For interactive units that add network-specific runtime and export requirements, extend the same release card with a route-by-route preflight such as Hookin’s playable ad network review checklist.

Sources

• Uploaded display ads specifications — Google Ads Help. Accessed September 9, 2026.
• Fix error messages with Uploaded ads — Google Ads Help. Accessed September 9, 2026.
• About HTML5/Playable ads for App campaigns — Google Ads Help. Accessed September 9, 2026.
• Fix issues with HTML5 assets for App campaigns — Google Ads Help. Accessed September 9, 2026.
• Guidelines for HTML5 display creatives — Display & Video 360 Help. Accessed September 9, 2026.
• HTML5 creatives — Display & Video 360 Help. Accessed September 9, 2026.
• Traffic HTML5 creatives — Google Ad Manager Help. Accessed September 9, 2026.
• Guidelines for HTML5 creatives — Google Ad Manager Help. Accessed September 9, 2026.
• Limitations of HTML5 creatives — Google Ad Manager Help. Accessed September 9, 2026.