A GIF has no alpha channel to delete. A frame is 8-bit indexed: at most 256 colours, and one index that may be flagged transparent. A translucent logo is composited onto the pixels first and then squeezed into that palette, so the only route is rebuild the pixels and quantise again. There is no metadata pass that helps, because a GIF carries no EXIF, no XMP and no C2PA box at all.
Measured on a 24-frame, 480 by 270 loop with a 124 by 40 translucent logo: patching it with ffmpeg's delogo takes the logo's rectangle from 12.69 dB to 22.94 dB against a lossless render of the same frames. The file then grows 31.3 percent, because the logo was the most compressible object in the frame. And the improvement is not spread evenly: 16 of the 24 frames come back at 33.08 dB, while the 8 frames where a bar passes under the logo average 19.52 dB and bottom out at 14.99 dB.
This is the part that decides everything else. A GIF frame is 8-bit indexed, which means the file does not store a colour per pixel. It stores one number per pixel, and that number is an index into a table of at most 256 colours. The table is either global, shared by the whole file, or local to one frame. Read the file the page was measured on and the header says GIF89a, a global colour table with 256 entries, 24 Graphic Control Extensions, and a NETSCAPE2.0 loop count of 0, which means it loops forever.
There is one transparency feature, and it is not alpha. A Graphic Control Extension can name one palette index as transparent. That flag means do not draw this pixel. It does not mean blend this pixel at 40 percent. A GIF cannot store partial opacity per pixel, so a translucent logo cannot be stored as a translucent layer that you later delete. What is stored is the result of the blend: the logo's colour already mixed with whatever was behind it, rounded to the nearest entry in the palette. That blended value is the pixel. Deleting the layer deletes the only copy of the picture underneath.
The practical consequence is that the "transparent index" trick does not remove a watermark, it punches a hole. Whatever shows through the hole is decided by the frame's disposal method, which is not the original picture but the previous frame, or the background colour, or nothing. On a loop where a bar moves, that means a frozen copy of the bar sitting in the hole.
And the second consequence is that none of the metadata routes apply. A GIF has no EXIF, no XMP, no C2PA manifest, no comment block that a viewer reads as a caption. Metadata stripping is a real operation on video containers, and it is a completely different job from this one. If the mark you can see is in the picture, no metadata pass will touch it.
Every number below comes from one script that rebuilds its own fixtures. The source is 24 lossless frames, 480 by 270 at 12 frames per second, two seconds: a two-stop gradient, one bar travelling left to right, a second element travelling the other way, and a 124 by 40 logo in the bottom-right corner, 3.83 percent of the frame. The logo is a white plate at 55 percent opacity with a dark rule through it, so it is neither a pure brightness offset nor a flat colour.
Two renders are made from that source, one with the logo and one without. The one without is the reference, and it is lossless, so no comparison below is between two lossy encodes. Then three GIFs are written from the marked render:
| File | What it is |
|---|---|
| G1 | The marked render encoded to GIF. This stands in for the file you downloaded. |
| A | G1 decoded and re-encoded, nothing removed. Isolates the cost of a second save. |
| B | G1 decoded, delogo over the logo box, re-encoded. The removal. |
| C | G1 with the logo's rows cropped away. The other honest answer. |
The control that makes the rest readable: the marked lossless render scored against the clean one measures infinite dB outside the logo's rectangle. Infinite, not "high", because outside that rectangle the two files are the same pixels. So any difference measured outside the box later in this page is caused by the GIF encoder or the filter, never by the logo.
The most common warning about GIFs is that every save degrades them. Measured here, that is false, and the measurement is blunt: file A has the same 53,704 bytes and the same MD5 as file G1. Decoding a GIF and re-encoding it with a palette generated from those same frames is a fixed point. Scored against the lossless reference, both files sit at 74.40 dB outside the box, which is a handful of pixels one level off, not a visible generation loss.
That matters because it removes the usual excuse. If the save were the problem, the fix would be to avoid saving. The save is not the problem. The patch is:
inside the logo box, vs the lossless render G1 the downloaded gif 12.69 dB A re-saved, nothing removed 12.69 dB B delogo, then re-saved 22.94 dB outside the logo box, vs the lossless render G1 74.40 dB A 74.40 dB B 47.32 dB
Two things to read in that second block. B at 47.32 dB outside the box is lower than A at 74.40, which is not a mistake: delogo builds its fill from a ring of pixels outside the rectangle, so its influence leaks a little past the boundary. At 47 dB the leak is far below anything you could see, but it is measurable, and it is the reason the "only the box changes" claim is never exactly true.
The caveat on the free re-save: it holds when the palette is generated from the frames. A tool that forces a fixed table, such as a 216-colour web-safe palette, or that dithers differently on every pass, will lose something on each save. The measured claim here is about a palette rebuilt from the data, which is what the commands on this page do.
Inside the box, the removal takes the measurement from 12.69 to 22.94 dB. That is a real gain: the logo is gone in the sense that the rectangle no longer reads as a white plate. It is also an average over 24 frames that hides the actual behaviour, because the 24 frames are not alike.
| Frames | What is under the logo | PSNR inside the box |
|---|---|---|
| 16 of 24 | Gradient only | 33.08 dB |
| 8 of 24 | A bar passing through | 19.52 dB mean, 14.99 dB worst |
| All 24 | Mixed | 22.94 dB |
The mechanism is in how delogo works. It does not know what was behind the logo; it reads a ring of pixels along the rectangle's four edges and interpolates inward. Over a smooth gradient, the ring describes the interior almost exactly, and 33.08 dB is close to the limit of what an 8-bit palette can carry anyway. When a bar crosses the box, the ring describes the gradient plus two slices of bar, and the interior is neither. The fill becomes a smear of the surrounding colours, and the measurement falls 18.09 dB from the flat frames to the worst one.
In a video that is a nuisance on eight frames out of twenty-four. In a GIF it is worse than that, because the file declares an infinite loop. Those eight frames are not eight frames you might miss; they are a third of a two-second cycle that plays until the reader scrolls away. A defect that would be a flicker in a video becomes the thing the loop is remembered for.
This is the part nobody warns you about. A translucent plate over a smooth background is a large region of nearly identical palette indices, and runs of identical indices are exactly what LZW, the compression GIF uses, encodes in a few bytes. So the logo barely costs anything to store. Measured:
| File | Bytes | vs the clean render |
|---|---|---|
| Clean render, no logo, same 24 frames | 53,130 | — |
| G1, with the logo | 53,704 | +574 bytes, +1.1% |
| B, logo patched | 70,506 | +17,376 bytes, +32.7% |
| B, patched with dithering off | 61,324 | +8,194 bytes, +15.4% |
Put the first two rows together. Adding the logo to a clean loop cost 574 bytes. Removing it again cost 16,802 bytes, which is 29 times what the mark itself cost. The repair is the expensive object, not the mark. And about half of the repair's cost is not the interpolation at all: it is the dither the encoder applies to the new gradient, which is why turning dithering off drops the growth from 31.3 to 14.2 percent.
The palette moves with it. The median frame carries 253 distinct colours with the logo in place and 178 after the patch, because the interpolated region needs fewer distinct values than the anti-aliased edge of the plate did. Fewer entries covering a smooth ramp is the definition of banding, which is the second cost: on a large GIF you may trade a visible logo for a faint contour in the corner.
If the file has a size limit, this is the number that decides whether the removal is usable at all. A 5 MB GIF that gains 31 percent is 6.5 MB, and several chat clients and forums cap attachments well below that.
If the logo sits in a strip you can lose, crop the strip. It is not a repair, so there is nothing to reconstruct: every pixel you keep is the pixel that was in the file. On the same fixture, cutting the logo's rows off took the frame from 480 by 270 to 480 by 206, 64 rows and 23.7 percent of the pixels. Scored against the reference on the area that remains, it measures 74.33 dB, which is the same handful of one-level differences as the untouched file. And it is smaller: 43,515 bytes, 19.0 percent below G1.
So the honest ranking for a corner logo in a GIF is: crop if the strip is spare, patch only if it is not, and never blur. Cropping is both cleaner and cheaper than patching, and the only thing it takes is picture you were not using. The same four options for a video, with their costs →
Read the logo's rectangle off one frame first. Guessing it by two pixels in any direction is the most common reason a removal looks wrong, because delogo interpolates from the ring immediately outside the numbers you give it, so a box that is too tight drags the logo's own edge into the fill.
# patch the rectangle, then rebuild the palette from the patched frames ffmpeg -i in.gif -vf "delogo=x=330:y=206:w=124:h=40,split[a][b];\ [a]palettegen=max_colors=256[p];[b][p]paletteuse=dither=sierra2_4a" \ -loop 0 out.gif # or crop the strip away, which needs no fill at all ffmpeg -i in.gif -vf "crop=480:206:0:0" -loop 0 out.gif
Then check it frame by frame, not by eye on the first frame. The measurement in this page exists because a single frame told the wrong story: frame 0 measures 33.08 dB and looks perfect, and the frame where the bar crosses measures 14.99 dB and does not. A quick way to see the whole file at once is to tile the frames and look for the ones where the fill has no edge to work from:
ffmpeg -i out.gif -vf "tile=6x4" -frames:v 1 contact-sheet.png
What you will find, if the logo sits over anything that moves, is that no setting fixes it. A larger box makes the smear larger. A smaller box leaves the logo's edge behind. That is not a parameter problem; it is the filter being asked for information that is not in the frame. The three layers a mark can live in, and which one this is →
Stated plainly, because it is the difference this whole page turns on: the tool on this site cleans text and still-image metadata. It removes invisible and zero-width characters, directional formatting marks, hidden class attributes, and EXIF, XMP or C2PA blocks from images. It does not rewrite pixels, and it does not touch a GIF.
That is not a gap in the tool, it is the boundary between two different problems. A logo in a GIF is visible to every reader, which means it is in the pixels, which means only a pixel operation can address it. A metadata block is invisible and can be removed without changing the picture by a single value. Confusing the two is how people end up paying for a "watermark remover" that returns the same image with the same logo. What a browser-side remover can and cannot reach →
Because a GIF's transparency is one palette index, not an alpha channel. A frame is 8-bit indexed: at most 256 colours, and one of those indices may be flagged as transparent. That flag means skip this pixel, not blend it. So setting the logo's pixels to the transparent index does not reveal the picture underneath, because there is no picture underneath. The mark was composited onto the pixels before the frame was quantised, and the composited value is what the palette stores. You get a hole, and what shows through the hole is whatever the frame disposal method leaves behind, which is usually the previous frame.
Not when the palette is rebuilt from the frames themselves. Measured here: decoding a 24-frame GIF and re-encoding it with a palette generated from those same frames produced a byte-identical file, same 53,704 bytes, same MD5. The error against the lossless source was zero, an infinite PSNR, and 74.40 dB outside the logo box both before and after. The usual warning about generation loss applies to tools that impose a fixed palette, such as a 216-colour web-safe table, or that dither differently on every pass. It does not apply to the save itself. In a GIF the loss is in the patch, not in the re-save.
Because delogo has nothing else to work from. It fills the rectangle by interpolating from a ring of pixels just outside it, so whatever is inside the box is replaced by a continuation of the edges. When the background behind the logo is flat, that continuation is almost exactly right: 16 of the 24 frames in the test loop came back at 33.08 dB. When something passes under the logo, the edge ring no longer describes what is in the middle, and the fill becomes a smear of the surrounding colours. Those 8 frames averaged 19.52 dB and the worst frame measured 14.99 dB, an 18.09 dB collapse on the same file with the same filter settings.
Yes, in this test it did, by 31.3 percent: 53,704 bytes became 70,506. The reason is that the logo was the cheapest object in the file. A translucent plate over a smooth background is a large run of nearly identical palette indices, which is what LZW compresses best; the clean version of the same 24 frames was 53,130 bytes, so the mark added only 574 bytes, about 1.1 percent. Replacing it with interpolated pixels costs 16,802 bytes, roughly 29 times what the mark itself cost. Disabling dithering in the encoder halves the growth to 14.2 percent, which tells you about half of it is the dither noise the encoder adds to the new gradient.
No. The browser tool on this site cleans text and still-image metadata: invisible characters, directional marks, hidden class attributes, and EXIF, XMP or C2PA blocks. A GIF logo is not metadata and is not a hidden character, it is pixels, and the tool does not rewrite pixels in any format. The commands on this page are ffmpeg, run locally on your own file. That distinction is the point of the whole page: a watermark that is visible in the picture cannot be cleaned off by a metadata pass, whatever the format.