A GIF can be the right dimensions and comfortably under 150 KB yet still be wrong for Google Ads. One file in the test set below is a 300 × 250 GIF weighing only 26,747 bytes. Its visible sequence lasts six seconds and runs at four frames per second. It still fails because its loop value tells the browser to repeat forever. Another file is just 22,987 bytes but lasts 31.5 seconds. A third lasts only four seconds but runs at 10 FPS.
For custom uploaded Display image ads, Google’s current specification is straightforward: GIF, JPG, and PNG are accepted image formats; the maximum file size is 150 KB; an animated GIF must be 30 seconds or shorter; looping is allowed only if the animation stops within 30 seconds; and the GIF must be slower than 5 FPS. These are published technical requirements, not an approval guarantee. Google’s separate image-ad policy still applies to quality, relevance, accuracy, and other content. See Google’s uploaded display ads specifications and image ad requirements.
The final frame needs a separate decision. Google’s current GIF specification does not say that the final frame must contain a logo, offer, or call to action. In the local Chromium playback used for these teaching files, each finite GIF remained on its decoded last frame after the motion ended. That made the final frame the longest-lived state in that playback and gives producers a strong reason to make it work as a complete static ad.
The requirements, translated into production checks
| Published rule or scope | What the producer must inspect | Conservative production gate used here |
|---|---|---|
| Uploaded image format: GIF, JPG, or PNG | Confirm the decoded file type, not only the extension | Animated file decodes as GIF |
| Maximum file size: 150 KB | Measure the finished export in raw bytes | No more than 150,000 bytes, with working margin below that ceiling |
| Supported fixed dimensions | Read the GIF canvas size | Exact match to a listed uploaded-display size |
| Animation length: 30 seconds or shorter | Add every encoded frame delay and account for every play | Effective runtime no more than 30.000 seconds |
| Looping is allowed, but the animation must stop after 30 seconds | Inspect loop metadata and observe a fresh playback | Infinite loop fails; any finite repeat must visibly stop by 30 seconds |
| Animated GIF must be slower than 5 FPS | Find the shortest encoded frame delay | Every frame delay greater than 200 ms; zero or missing delays require review; 250 ms gives 4 FPS |
| Standard image-ad policies also apply | Review the actual message and design | Technical pass is not treated as platform approval |
| No published final-frame content rule | Inspect the decoded last frame as a static ad | Human review for brand, message, CTA, legibility, and accuracy |
Two scope boundaries matter. First, this article is about the custom uploaded image-ad workflow described on Google’s specification page, not every image or video asset accepted by every Google Ads campaign type. Google separately describes responsive display ads as an asset-based format that Google assembles and adapts. Second, the 150 KB GIF rule should not be mixed with the separate limits for uploaded HTML5 or AMPHTML packages. Google’s responsive display overview and uploaded-ad specification keep those formats distinct.
Six GIFs that all fit under 150 KB—but do not all pass
The following files are original fictional teaching assets. They are not live campaign creatives, observed brand ads, or Google approval results. All six are 300 × 250 and below 150,000 bytes so that animation behavior, rather than basic size, makes the difference.
| Demo | Encoded measurement | Loop metadata | Result | What it teaches |
|---|---|---|---|---|
| A — finite replay | 85,606 bytes; 79 frames; 27.0 s; max 4 FPS | Absent | Technical pass | Three visible message replays are expanded into one finite timeline, followed by a complete final frame |
| B — infinite loop | 26,747 bytes; 24 frames; 6.0 s per pass; max 4 FPS | 0 |
Fail | A short cycle is still invalid when it never stops |
| C — 10 FPS | 41,064 bytes; 40 frames; 4.0 s; max 10 FPS | Absent | Fail | Size and duration pass, but the frame rate is too high |
| D — 31.5 seconds | 22,987 bytes; 32 frames; 31.5 s; max 2 FPS | Absent | Fail | A slow, finite animation can still exceed the duration limit |
| E — weak final frame | 25,126 bytes; 33 frames; 12.0 s; max 4 FPS | Absent | Technical pass; creative review | The file meets the measured technical gates but ends with no useful brand, offer, or CTA |
| F — exactly 5 FPS | 11,573 bytes; 20 frames; 4.0 s; exactly 5 FPS | Absent | Conservative fail | Google says “slower than 5 FPS,” not “5 FPS or slower” |
The measurements above come from the encoded GIFs, not from a design timeline. That distinction is essential: an optimizer can merge frames, change delays, or write loop metadata during export. The deliverable is the file Google receives, so the final file is what must be audited.
Test 1: measure the real file size and canvas
Google publishes “150 KB” without defining decimal versus binary kilobytes on the cited specification page. Do not invent a conversion and present it as Google’s. A safe internal approach is to measure raw bytes, use 150,000 bytes as a conservative ceiling, and leave margin rather than exporting to the exact edge. The included validator reports both decimal KB and KiB so the number cannot be misunderstood.
The current uploaded-display specification lists these dimensions:
| Category | Listed dimensions |
|---|---|
| Square and rectangle | 200 × 200, 240 × 400, 250 × 250, 250 × 360, 300 × 250, 336 × 280, 580 × 400 |
| Skyscraper | 120 × 600, 160 × 600, 300 × 600, 300 × 1050 |
| Leaderboard | 468 × 60, 728 × 90, 930 × 180, 970 × 90, 970 × 250, 980 × 120 |
| Mobile | 300 × 50, 320 × 50, 320 × 100 |
Google notes that some sizes are available only in certain regions, so the specification page should remain the source of truth for the campaign’s market. Do not resize a 300 × 250 concept to an arbitrary near-match such as 300 × 249. The canvas must match a listed size exactly.
A useful working target is lower than the hard gate—perhaps 140,000 to 145,000 bytes—because late copy changes, palette changes, or exporter settings can increase the file. That margin is an internal production choice, not an additional Google rule.
Test 2: calculate timing from encoded frame delays
A GIF does not carry one universal “duration” field in the way a video file often does. Each rendered frame can have its own delay. The GIF89a specification stores that delay in hundredths of a second, and the total one-pass duration is the sum of those delays. The GIF89a specification defines the frame delay in the Graphic Control Extension; Pillow’s GIF documentation exposes the decoded duration in milliseconds.
The basic calculation is:
one-pass duration = frame 1 delay + frame 2 delay + … + final frame delay
The final-frame hold counts. If the last image is displayed for 7.5 seconds, those 7.5 seconds are part of the 30-second budget even though nothing moves during the hold.
Demo A uses a filled production timeline rather than a vague “under 30 seconds” instruction:
| Segment | Time | Construction |
|---|---|---|
| Message pass 1 | 0.0–6.5 s | Hook, product, benefit, CTA |
| Message pass 2 | 6.5–13.0 s | Same sequence replayed inside the file |
| Message pass 3 | 13.0–19.5 s | Same sequence replayed inside the file |
| Complete final frame | 19.5–27.0 s | Brand, product, message, and CTA held for 7.5 s |
| Total | 27.0 s | 78 motion frames at 250 ms plus one 7,500 ms final frame |
The arithmetic is 78 × 0.25 + 7.5 = 27.0 seconds. The shortest delay is 250 ms, so the fastest part is 4 FPS. The exported file contains no loop extension and therefore plays this 27-second timeline once.
Demo D shows why “it looks slow” is not a timing test. It changes only once per second for most of the sequence, but the encoded delays total 31.5 seconds. The encoded timeline includes a change at 30 seconds and reaches its final frame at 31 seconds, followed by a 0.5-second hold. Browser playback also showed the late counter and final state; the precise timing here comes from the decoded delays. Slow animation is still over-length animation.
Frame rate needs the same arithmetic. A 100 ms frame delay equals 10 FPS, which is why Demo C fails. A 200 ms delay equals exactly 5 FPS. Because Google’s current wording is slower than 5 FPS, this package treats Demo F as a conservative fail and uses 250 ms, or 4 FPS, for the valid example. Google does not publish the details of its evaluator on the cited page, so it is better to build an unambiguous file than to argue about a boundary value.
Test 3: inspect the loop, not just one pass
A duration readout that says “6.0 seconds” can describe only one traversal of the frame sequence. It does not prove that the animation stops.
Demo B has a six-second one-pass duration and a maximum of 4 FPS, but its loop metadata is 0. In the decoder used for this package, 0 means infinite looping. Browser playback confirmed that the creative changes and repeats instead of remaining on the CTA. The six-second cycle is measured from the encoded frame delays. The file is small, slow enough, and short per cycle, yet it violates the requirement to stop within 30 seconds.
Positive finite loop counts also deserve a real playback test. Exporters may label repeats in ways that invite off-by-one mistakes: “loop twice” can be read as two total plays or two repeats after the first play. Rather than trusting the authoring interface, inspect the encoded loop value and reload the finished file in a browser. Observe it past the expected stop time and, for any borderline sequence, past 30 seconds.
A robust production pattern is the one used in Demo A: put the desired repeated message passes directly into one finite timeline, omit the loop extension, and reserve the remaining time for a final hold. That is not the only valid implementation, but it removes loop-count ambiguity from the handoff.
Test 4: judge the final frame as a static ad
The final-frame check is editorial, not a hidden Google specification. Keep that distinction clear. A blank or half-transitioned last frame may still satisfy the published duration, loop, speed, dimension, and file-size rules. It is nevertheless a weak deliverable because the viewer can spend more time seeing that state than any moving scene.
Demo E makes the difference visible. It is 25,126 bytes, 12 seconds long, 4 FPS at its fastest, and has no loop extension. It passes the measured technical gates. It then stops on a nearly empty composition: no brand, no product name, no message, and no CTA.
Use the decoded last frame—not a screenshot taken while the timeline is still moving—and ask five questions:
- Can a viewer identify the advertiser or product? A logo alone may not explain an unfamiliar offer; a product name without a brand may be equally weak.
- Does the frame preserve the core message? It should not depend on a sentence that disappeared two seconds earlier.
- Is the action clear? A CTA is not a published GIF requirement, but it is usually useful when the campaign expects a click.
- Is every claim still accurate without the animation’s context? Do not leave a price, discount, timer, or availability statement that becomes misleading when frozen.
- Is it visually complete? Check for clipped copy, transition residue, invisible text, an empty stage, or a product that moved off-canvas.
The correct final frame is not necessarily crowded. Demo A uses a product, brand, short descriptor, and one CTA. The point is not to repeat every earlier line; it is to leave a coherent static decision frame.
Run a practical preflight on the exported GIF
Download the local GIF preflight checker, a Pillow-based Python utility. It reads the encoded dimensions, byte size, frame count, per-frame delays, one-pass duration, and loop metadata; applies the conservative gates described above; and can extract the first and final frames for human review.
python HB58_gif_preflight_v1.py creative.gif \
--json creative_report.json \
--extract-dir extracted_frames
The script deliberately does not claim to validate message quality or predict Google approval. A machine can extract the final pixels; it cannot reliably decide whether those pixels communicate the correct offer.
A complete handoff check is:
- Confirm that the ad is being prepared for the uploaded Display image-ad workflow and that GIF is the intended format.
- Measure the finished file’s raw bytes and decoded canvas dimensions.
- Sum encoded frame delays; record the shortest delay and calculated maximum FPS.
- Read loop metadata, then open a fresh copy in a browser. Confirm that it stops no later than 30 seconds and remains stopped.
- Extract and review the final frame at 100% size. Read every word and compare the offer with the destination page.
- Re-run the entire check after the last optimization or copy change. Do not approve the source project and assume the export is identical.
The accompanying visual test board lets an editor restart each original GIF or switch immediately to its decoded first and final frames. The measurement report records raw bytes, SHA-256 hashes, frame delays, loop metadata, and gate results for all six examples.
Compress without destroying the timing plan
The 150 KB ceiling forces tradeoffs, but random frame deletion is a poor optimization strategy because it can change pacing, copy readability, and the final stop.
Start with the changes that preserve the intended message:
- Use a restrained color palette and avoid photographic noise when the concept can work with flat graphics.
- Animate a small region instead of redrawing the entire canvas when possible.
- Build at 4 FPS rather than exporting at 10 or 15 FPS and trying to repair it later.
- Replace unnecessary micro-motion with longer holds that give copy time to be read.
- Remove decorative frames before cutting the product, proof, or CTA sequence.
- Preserve a deliberate final-frame hold, then recalculate the full duration.
After optimization, inspect the encoded file again. Palette reduction, duplicate-frame removal, and GIF optimization can produce a different frame structure from the design application. The size win is irrelevant if the process writes an infinite loop, creates a 200 ms boundary frame, or removes the intended final state.
If the idea depends on smooth full-motion footage, many colors, or complex transitions that cannot remain legible below 150 KB and below 5 FPS, the concept may be a poor fit for GIF. Reconsider the creative or evaluate a separate supported format such as HTML5 under its own current eligibility and package requirements. Do not silently apply GIF limits to a different format.
What a passing file actually means
A technical preflight answers a narrow but important question: does the exported GIF appear to satisfy the published format, size, dimension, duration, loop, and speed constraints under the conservative interpretations stated here?
It does not guarantee acceptance. Google’s image-ad policy also calls out image quality, unclear relevance, misleading content, and the broader Google Ads policies. A 27-second, 4 FPS, 85 KB GIF can still be disapproved for what it says or shows. Conversely, a useful final frame is not a substitute for the 30-second stop rule.
The production sign-off should therefore contain two separate decisions:
- Technical: supported size, below the file limit, strictly below 5 FPS, finite effective runtime no more than 30 seconds.
- Editorial: clear and accurate message throughout, with a final frame that works after the motion has ended.
That separation catches the files that “look fine” in a folder but fail after export: the tiny infinite loop, the short 10 FPS animation, the slow 31.5-second sequence, and the technically valid GIF that ends on nothing.
Sources
- Uploaded display ads specifications — Google Ads Help. Current limits and supported uploaded-display dimensions; actually checked September 9, 2026.
- Image ad requirements — Google Advertising Policies Help. Animation policy and related image-ad policy areas; actually checked September 9, 2026.
- About common sizes for responsive display ads — Google Ads Help. Scope distinction between responsive display ads and advertiser-supplied image ads; actually checked September 9, 2026.
- GIF89a Specification — CompuServe specification mirrored by W3C, document dated July 31, 1990. Frame-delay representation; actually checked September 9, 2026.
- Image file formats: GIF — Pillow documentation. Decoded frame duration and loop metadata used by the included local checker; actually checked September 9, 2026.
