A Vegas Pro watermark is a compositing layer, and that is the whole answer. Vegas mixes tracks into one output, and a logo or a plugin stamp is added on a track above the footage. So the mark was never part of the video underneath it, and the fix is to stop compositing it and export again. Two of the three possible sources cost you nothing in quality:
1. A watermark event you or a template placed on a track. Delete the event, re-render. The footage pixels come back exactly as they were.
2. A bundled plugin running in unlicensed mode. Boris FX documents this one in writing: all unlicensed plugins "will feature a watermark". The fix is a setting, not a repair.
3. A mark already burned into a file you were handed. This is the only case that is genuinely pixels, and repairing it costs a second full encode.
What is not on that list is the trial. The vendor's own trial page describes a "full-featured" 15-day trial and lists no watermark among its limits. If you are looking at a mark, it came from layer 1 or layer 2.
| Source | How to confirm it in two minutes | Clean fix? |
|---|---|---|
| Your own watermark event, or a template's | Look at the timeline: the mark is an event on a track above the footage. Solo the footage track and it disappears from the preview. | Yes - delete or mute the event, re-render |
| A bundled Boris FX plugin in unlicensed mode | Bypass that effect and export a test frame. If the mark goes with the effect, it was the effect. | Yes - show licensed plugins only, or license it |
| A mark already burned into a file you were given | The mark is in the source file before it ever enters the project | No - pixels |
| Vegas Pro itself, on a render | - | Not the cause; the trial page lists no watermark |
That table is worth five minutes, because the top two rows end with a file that is better than anything a patch can produce. If you are working in another editor, the same three-layer split applies: the three layers a video mark can live in →
This is the one source with a vendor instruction that names it, so it is worth reading in the vendor's own words rather than a paraphrase. From the Boris FX support knowledge base, on a watermark appearing over the image:
"Continuum is a suite of over 250 plugins. Your license for the VEGAS Pro 19/20 entitles you to license a small portion of our plugins. Upon installation, you are given the option to either "show all plugins" or "show licensed plugins". Choose "show all plugins" to see everything Continuum has to offer, but be aware all unlicensed plugins will feature a watermark. If you choose to "show licensed plugins", only the plugins you have licensed will be shown in the VEGAS video effects tab."
Two things follow from that, and both are useful. First, the mark is conditional on a plugin being loaded, which is why bypassing the effect makes it vanish and why the fix is a dropdown rather than a repair. Second, the knowledge base question is literally "How do I get rid of the watermark over the image?" - this is a documented, expected behaviour of the bundled suite, not a fault in your render.
The same logic covers the wider case. Any effect, transition, template or generator that is running in demo mode draws its stamp at render time, which means it behaves exactly like an export setting: remove the effect and the stamp is gone from the next render. That route also happens to be the cheapest one, because a licence is less work than a patch and produces a better file.
The second layer is the one people forget they own. Vegas builds its output by compositing tracks, and the official manual is explicit about the direction of that stacking:
"Compositing is the process of mixing video tracks to create a single layered output."
"Since lower tracks show through higher tracks, it is the compositing mode of the higher track that determines how much of the lower track shows though."
And the manual's own recipe for a logo or a title overlay puts it on that higher track, twice, in the same words:
"If you want text to appear as an overlay, add it to a track above the video you want to overlay and use a transparent background."
"Add the image as an event to the track above the track containing the background."
Read that as a statement about where the mark lives. It lives on a track. The footage track below it still holds the original frames, unmodified, because compositing happens on the way out. So the correct fix is not a repair at all: mute or delete the watermark event, export again, and the output is the footage you started with plus one generation of compression. Nothing is invented, nothing is reconstructed, and no region of the frame is destroyed.
That is also why the wrong fix is so tempting and so costly. If you export first and patch afterwards, you are repairing a flattened copy of a problem that the project could have solved for free.
Layer three is the only one that needs pixels, so it is the only one worth measuring. The test below builds the exact situation: a source timeline, a watermark event composited over it, and then the two routes out.
| Route | What it produces | PSNR against a clean re-render |
|---|---|---|
| Re-render with the watermark event muted | The clean render itself - one generation | 44.22 dB against the lossless timeline |
| Patch the delivered export, then encode again | A repaired file - two generations | 29.23 dB |
| - outside the watermark box | Pixels you never touched | 41.48 dB |
| - inside the watermark box | The patch itself | 11.87 dB |
Two numbers in that table are the point of this page. The first is 44.22 dB: re-rendering without the event costs one generation of compression and nothing else, which is the price of exporting at all. The second is 41.48 dB - the region outside the watermark box, where the patch changed nothing, still dropped roughly 2.7 dB because the whole frame went through the encoder a second time. You do not pay for the repair in the repair; you pay for it across the entire picture.
Now look at what the mark actually damages, before anyone touches it. Comparing the watermarked export against the clean one:
whole frame 28.08 dB outside the mark's box 42.81 dB inside the mark's box 10.61 dB
The damage is confined to one rectangle. Outside it, the two files are effectively the same picture. That is the strongest argument for the project route: the only thing wrong with your file is a rectangle that a compositing layer put there, and a compositing layer is a switch.
The fixtures are built with ffmpeg, at 960x540, 25 fps, 3 seconds, H.264 CRF 23 preset medium, with the watermark event modelled as a 180x50 overlay at (760, 20):
ffmpeg -f lavfi -i testsrc2=size=960x540:rate=25:duration=3 \ -c:v libx264 -qp 0 -pix_fmt yuv420p master.mp4 ffmpeg -i master.mp4 -i logo.png -filter_complex "[0:v][1:v]overlay=760:20" \ -c:v libx264 -crf 23 -preset medium marked.mp4 ffmpeg -i marked.mp4 -vf "delogo=x=761:y=21:w=178:h=48" \ -c:v libx264 -crf 23 -preset medium patched.mp4 ffmpeg -i clean.mp4 -i patched.mp4 -lavfi psnr -f null -
Two disclosures, because they change how you read the table. First, this machine does not have Vegas Pro installed, so the fixtures model the compositing step with ffmpeg rather than coming out of a Vegas export - the layer structure is the part that transfers, not the bit-exact numbers. Second, testsrc2 has fine detail in every corner, which is the worst case for the interpolating patch inside the box: a real clip with a flat sky or a plain wall behind the mark would score considerably better than 11.87 dB there. The 2.7 dB cost outside the box is not pattern-dependent, because it is just an extra encode.
Because "remove watermark" searches often land on metadata tools, it is worth separating the two layers with a measurement rather than an assurance. Running this site's own container cleaner over the watermarked test file above:
freed /moov/udta/meta/ilst/(c)too = Lavf63.1.101 36 bytes file size 533,800 -> 533,800 bytes video payload 9e30f9282d47e4e7c73b700eba08dfc2 (unchanged)
The tag was removed and the video payload is byte-for-byte identical, which is exactly what a container cleaner is for - and exactly why it cannot help with a burned-in mark. Metadata and pixels are different layers, and a watermark drawn over the picture lives in the second one. What the container layer holds, and how to strip it without re-encoding →
Same decision tree in other editors: Premiere Pro and Final Cut Pro. And if you only need the file's metadata gone, that is a different job with a different tool - the cleaner on the home page does that one locally.
Not according to the vendor's own trial page. It describes a "15-day full-featured trial of Vegas Pro Ultimate" with "No credit card required", and the activation flow ends with "Vegas Pro will launch in unrestricted trial mode". No watermark appears anywhere in that list of what the trial is and is not. The limitation the page does state is time: fifteen days. So if you are seeing a mark on a trial render, the two live candidates are a watermark event on a track and a bundled plugin running unlicensed - both covered above, and both cleared without repairing a single pixel.
Almost always because an unlicensed plugin drew it. Boris FX answers this one directly in its support knowledge base: the bundled plugin suite gives you the choice between showing all plugins and showing only licensed ones, and with all plugins shown, "all unlicensed plugins will feature a watermark". Switch the list to licensed only and the stamp stops being composited; license the plugin and you get it back without the stamp. The other candidate is a watermark event sitting on a track above the footage, which you can see on the timeline and mute in one click.
Find the layer first, because the answer differs completely by layer. If the mark is an event on a track above the footage, delete or mute that event and re-render: compositing happens on the way out, so the footage track still holds the original frames and nothing needs repairing. If the mark is a plugin in unlicensed mode, change the plugin list or license the plugin. If the mark is already burned into a delivered file with no project behind it, you are in pixel territory, and the honest options are a crop, a masked patch, or a tracked fill - each with a cost, none of them a restoration.
It can cover it, but it cannot restore what was underneath, and no editor can - the marked pixels were overwritten when the mark was composited into that file. What Vegas gives you is a good set of covering tools: crop to drop a marked edge, a mask so an effect applies only inside the marked region, and tracking so the mask follows a mark that moves. What it does not give you is the original pixels, because they are not in the file any more. If you can obtain the project or the clean source instead, that is strictly better than any of these.
No, and the measurement above shows why in one line. Our container cleaner removed the file's user-data tag and left the video payload at exactly the same MD5 - 533,800 bytes in, 533,800 bytes out, not one pixel touched. Container metadata and picture content are separate layers. A mark drawn over the image lives in the picture layer, so a metadata tool changes nothing about it. What metadata stripping is genuinely good for is the other problem: the tags that record which app wrote the file, when, and with what settings.
The layer logic does, because it is about how the software composites tracks, and that has not changed. The specific plugin answer has a version caveat: the Boris FX knowledge base article above names the VEGAS Pro 19 and 20 licences and the Continuum suite, so the exact wording of that fix is scoped to those bundles. On an older perpetual licence the bundled plugin set and its licensing rules are different, and the reliable way to identify the source is still the same two-minute test - bypass the suspect effect and export a frame. If the mark goes with the effect, it was the effect.