Two different things get called the YouTube watermark, and only one of them is in the file. The small square that sits in the corner of the player is a channel setting: Google's own API documentation describes it as an image that "displays during playbacks of a specified channel's videos", set with a channelId and deleted per channel. It is drawn by the player while the video plays, so it is not stored in the video — the file is the same file whether the mark is on screen or not, and a download of that video does not contain it. There is nothing there to remove.
The other case is a logo the uploader burned into the picture, or a handle baked in by whatever a clip was reposted from. That one is pixels, and it is a real removal with a real price. Measured here on a 16:9 fixture, a corner square covering 1.09% of the frame reads 8.40 dB inside the mark if you leave it in, 26.71 dB through a delogo box, and 52.29 dB if the pixels are carried back from other frames. Cropping it off is billed in picture, and that bill is set by the frame's short side: the same square costs 25.86% of a 16:9 picture against 15.07% of a 9:16 one.
The reason "remove the YouTube watermark" has a wrong answer is that the phrase covers two objects. The first is the small square in the corner of the player, and the platform documents what it is. Google's YouTube Data API has a watermarks resource, described in its own documentation (read on 12 October 2026) as an image that "displays during playbacks of a specified channel's videos", and the two methods on it are watermarks.set — "Uploads a watermark image to YouTube and sets it for a channel" — and watermarks.unset — "Deletes a channel's watermark image".
Every part of that shape says the same thing. The required parameter is a channelId, not a video id. The timing object is a display schedule, with an offset from the start or the end and a visible duration in milliseconds — a description of when to draw something, not of something baked into a render. And the resource's position field is marked as deprecated and ignored, with the note that "Watermarks always display in the upper right corner of the video player" — of the player.
A channel-level resource is not a video resource. Set one and it applies to every video on the channel without re-uploading any of them; unset it and it is gone from all of them. That is only possible if nothing was ever written into the videos. So if the mark you want gone is this one, there is no file to repair: a downloaded copy of the same video already does not contain it, and a tool that offers to remove it from your file is selling you a fix for a file that is already clean.
Where the sources disagree, we say so. The API documentation puts the mark in the upper right corner of the player, while the setup guides we read describe the square in the bottom right. The API's own position field is deprecated and ignored, so the corner is the platform's choice and not something the docs pin down. We are not going to resolve that here; the corner it sits in does not change anything below, because the arithmetic depends on the square's size and on which edges it is near, not on which corner.
If the mark is not in the file, then a file should show no trace of it — and a container has nowhere to put one. That is checkable, and it is the reason the container layer is the layer that comes off with zero bytes changed: the records a video actually carries are things like the encoder string and the track handler name, not a description of anything drawn over the picture.
On the fixture used below, ffprobe returns seven tag lines and not one of them is a watermark:
ffprobe -show_entries format_tags:stream_tags clean.mp4 TAG:language=und TAG:handler_name=VideoHandler TAG:encoder=Lavc63.1.101 libx264 TAG:major_brand=isom TAG:minor_version=512 TAG:compatible_brands=isomiso2avc1mp41 TAG:encoder=Lavf63.1.101
What that list contains is a statement about who last wrote the file — the encoder — which is a different kind of fact from anything about the picture. There is no field for a watermark, so there is nowhere for a player's overlay to have been recorded, and nothing in the file to strip. Records that are in a file — container tags, a C2PA provenance box — are a separate subject with its own measurements, on the page about removing metadata from a video.
The second case is a logo the uploader burned into the picture — a channel bug, a sponsor card, a handle from whatever the clip was reposted from. This one is pixels, and it is the case the rest of this page measures. The fixture is a 16:9 clip — 960x540, 30 fps, 30 frames, H.264 at CRF 20 — with a photographic plate under it (luma standard deviation 62.3, so there is real detail for a PSNR to mean anything), and a 75x75 square in the bottom-right corner, 24 pixels from the edges, painted into the picture at 50% strength. That square is the same share of the short side as a 150-pixel mark on a 1080p frame.
| Route | Measured against the clean file | What it costs |
|---|---|---|
| Leave the mark in | 28.03 dB whole frame; 8.40 dB inside the mark | Nothing, and the mark stays |
| delogo box, 75x75 | 26.71 dB inside the box; 52.70 dB outside | An interpolated patch where the mark was |
| Pixels carried back | 52.29 dB | Nothing invented; needs motion |
Read the middle row carefully, because it is the one that surprises people. The box is the same size as the mark, so almost everything inside it was marked and has to be guessed — 26.71 dB is a large gain over the 8.40 dB of leaving the mark in, and it is still a visible patch. The third row is a different kind of answer: the mark is fixed in the corner, but the background behind it pans, so the picture it hides is on screen, unmarked, at another moment. All 168,750 of the marked pixels across the clip are exposed somewhere, and copying them back reaches 52.29 dB — 24 dB better than the box, with no pixel invented at all. The condition is relative motion between the mark and the picture; a locked-off shot with a locked-off logo fails it. The full comparison of the three routes, including the semi-transparent case, is on the page about removing a logo from a video.
Cropping is the one route that invents nothing: you delete the strip the mark sits in, and what is left is real pixels. That makes its price easy to state exactly, and it exposes something the method comparisons miss. A corner square is removed by cropping a strip as wide or as tall as the square, and that strip is a fixed number of pixels. So its share of the picture is set by the frame's short side — and 150 pixels is a much bigger share of 1080 than of 1920.
| Crop, for a 150 px square | 1920x1080 (16:9) | 1080x1920 (9:16) |
|---|---|---|
| The bottom strip | 13.89% of the frame | 7.81% of the frame |
| The right strip | 7.81% of the frame | 13.89% of the frame |
| Both, to keep the aspect ratio | 25.86% of the frame | 15.07% of the frame |
The two frames have exactly the same area, and the same square is removed from each, yet keeping the aspect ratio costs 25.86% of one and 15.07% of the other — 1.72 times more on the landscape frame. The mechanism is not subtle once it is stated: the crop has to take a fixed 150 pixels off the short side, and on a 16:9 frame the short side is the one you have least of. If you are choosing between cropping and interpolation, that ratio is part of the decision, and it is not visible in any of the usual "crop or blur" advice.
There is one more way the two cases get confused, and it is the one that actually creates the problem. Because the corner mark is not in the video, nothing in the video changes while it is on screen. But a screen recording is not a copy of the video — it is a new file that captures what was on the screen, overlay included. That is where a player setting becomes pixels:
clean.mp4 32,512 B md5 61586a78949e... recorded.mp4 31,215 B md5 84d95f365469... (a different file, not a copy) recorded vs clean, whole frame 28.03 dB recorded vs clean, inside the mark 8.40 dB
Two things follow. The recording is a genuinely different file — a different checksum, produced by a second encode — so it is not a lossless way to get a clean copy of anything. And the overlay is now 5,625 pixels of destroyed picture that did not exist in the source. If you recorded the screen specifically to avoid a watermark, the recording is what put one in the file; the download of the same video was the copy that did not have it. That is also why the mark on a reposted short behaves differently from the player's corner mark: a reposted clip carries whatever the source baked into it, which is pixels, and that case is measured on the page about a saved short-form video.
Whichever it turns out to be, the question after any edit is what the file still contains — the audio, the subtitles, the duration, the sync. That is a separate set of checks, measured on the page about what survives the edit.
watermarks resource quotes above are from developers.google.com/youtube/v3/docs/watermarks, read on 12 October 2026. YouTube's own help page for the branding watermark returned no text to this machine, so no quotation from it appears here and none is implied.The corner mark is not. Google documents it as a channel resource: the YouTube Data API has a watermarks resource that it describes as an image that "displays during playbacks of a specified channel's videos", with a set method that takes a channelId and an unset method that deletes the channel's watermark. A channel-level setting is applied by the player while the video plays, so it is not stored in the video itself — the file is the same file whether the mark is on screen or not, and a download of that video does not contain it. What is in the file is a logo the uploader burned into the picture, which is a different problem with a real cost.
There are two answers because there are two marks. If the mark you are pointing at is the player's corner mark, there is nothing in the download to remove — it was never in the file, so a downloaded copy already does not have it. If the mark is a logo the uploader burned into the picture, it is pixels, and removing it means paying one of three prices, all measured above: crop the strip it sits in and lose that strip, interpolate over it with a delogo box, or carry the pixels back from the frames where the same background is on screen unmarked.
Because a corner mark is removed by cropping the strip it sits in, and that strip is a fixed number of pixels. A 150-pixel square needs a 150-pixel strip, and 150 pixels is a bigger share of a short side than of a long one. Worked out for two frames of the same area: cropping the strip off a 1920x1080 video costs 13.89% of its height, while the identical square on a 1080x1920 video costs 7.81%. If the aspect ratio has to be kept, the crop takes from both axes, and the same square then costs 25.86% of a 16:9 picture against 15.07% of a 9:16 one — about 1.7 times more.
Yes, if the picture under it is on screen unmarked somewhere else in the same clip. On the fixture measured here the mark is fixed and the background pans, so every one of the 168,750 marked pixels across the clip appears without a mark in another frame, and copying those pixels back measured 52.29 dB against the clean file — against 28.03 dB for leaving the mark in and 26.71 dB inside the box for a delogo pass. The condition is relative motion between the mark and the picture; a locked-off shot with a locked-off logo fails it, and then cropping or interpolation are the only routes left.
It puts the player's overlay into a file for the first time. The overlay is not in the video, so nothing in the video changes while it is on screen; but a screen recording is a new file that captures what was on screen, overlay included. Measured here: the recording has a different checksum from the file it was recorded from, and the overlay is now 5,625 pixels of destroyed picture, reading 8.40 dB inside the mark against the clean original. Recording to get a clean copy is the step that creates the problem you were trying to avoid.
That one is pixels, not a player setting, so it is a real removal — and it is the case that breaks a fixed box, because the mark is not in one place. It is measured in detail on the page about removing a TikTok watermark: on a 9:16 fixture there, the two overlays cover 1.44% of the frame, a box big enough to cover them for the whole clip covers 31.85%, and the same movement is what makes carrying the pixels back possible at 53.73 dB.