Dynamic Watermark switch
A single on/off switch on the upload page. There is no watermark type to pick and no style options — it is on, or it is off. Links made today carry the text mark.
MaiPDF draws a mark across the page as the PDF opens. What it shows is a code for that one open — not your reader’s personal details. Take the code off a leaked screenshot, look it up, and you get the browser, IP and time behind it. You can’t stop every screenshot, but you can make every copy point at a single session.
The mark matters because it stays inside the same managed share route instead of becoming a detached graphic treatment.
flowchart LR
A["Upload PDF"] --> B["Turn on watermark"]
B --> C["Set view mode"]
C --> D["Send route"]
D --> E["Check records later"]
Start with the document that should stay attributable during viewing.
Flip the Dynamic Watermark switch before you upload. It cannot be switched later without replacing the share.
The reader still receives one governed browser route.
The owner can still inspect the share afterwards.
On links created today the visible mark is text — the record number for that open, repeated across the view. There is no style to choose.
The number is issued as the document opens, so two readers of the same file never carry the same mark.
Watermarking becomes more credible when the PDF is already inside SecureView — or, for genuinely sensitive files, inside the app.
The owner still keeps the larger access-record layer after launch.
The watermark behaves differently depending on which route you share by. Online it is something you turn on; in the app it is simply always there.
A single on/off switch on the upload page. There is no watermark type to pick and no style options — it is on, or it is off. Links made today carry the text mark.
What appears on the page is the record number for that one open — not the reader’s details. Those sit in the record the number points to: the verified email address if email verification was on, and the IP, browser and open time in every case. Only you can look them up, so the reader’s address is never exposed to anyone else who sees the page.
The app reader stamps every page with a code tied to that licence and device. There is no setting for it anywhere in the packaging flow — you cannot turn it off, and neither can the reader.
Online, setting the open limit above 10,000 switches the link into unlimited mode, and Dynamic Watermark becomes unavailable along with access records. If you need the mark, keep the limit at or below 10,000.
Both routes work the same way underneath: at the moment a document is opened, a unique code is drawn into the pages being displayed, so a leaked image can be traced back to that one open. What differs is what the code is tied to — and whether you get a choice about having it.
Why the app forces it. An App DRM file travels to the reader and is opened away from your server, so there is no live gate to lean on afterwards. The watermark is the one control that keeps working once the file has left — including against the attack nothing else stops, a camera pointed at the screen. Making it optional would let people switch off the only protection that survives that.
Why online leaves it to you. An online share is already gated on every open, and the visible mark costs something in readability. For an ordinary document the gate and the records may be enough, so it stays your call — but for anything sensitive, turn it on.
What is the same either way. Neither mark is baked into the stored PDF. Both are drawn at the moment of opening, so the same file shows a different code to a different reader, and the code you find on a leaked screenshot points at one specific open rather than at the document in general.
The useful part is not just the visible overlay. It is that the mark stays connected to the same controlled share the owner can still inspect later.
The mark sits on the page itself
Marks are drawn over the document in the reader, repeated across the page so a crop still carries one. This particular capture comes from an older reader route that drew the mark as QR codes; links created today use the text mark instead, and old links keep working as they are.
One switch, with the other rules
Dynamic Watermark sits in the same upload form as open limits, session length and view mode — a single on/off switch, decided before you share.
Watermarking is most useful when attribution or later review matters. It is one signal inside a broader controlled-share workflow.
A lawyer sends a draft to several parties. Every open carries its own code, so a page that surfaces outside the intended group can be matched back to the exact session that produced it — and from there to the browser, IP and time in the record.
A PR team sends an embargoed release to journalists. Each open gets a distinct code, so if the story runs early, a leaked screenshot narrows the question to one session rather than the whole distribution list.
A designer shares a portfolio PDF with potential clients. A visible watermark reminds readers that the copy is attributable and may discourage casual reuse. Attribution still depends on how the material is later used.
A finance team circulates an investor briefing. Because the code is issued per open rather than per file, forwarding the link does not blur the trail — whoever opens it next generates a new code of their own.
Practical answers to the questions that come up before enabling watermarks.
A number — the record number for that one open — repeated across the view as faint moving text. The reader’s email, name and IP are never printed on the document itself. They live in the access record that number points to, which only you can look up: the verified email address when email verification was on, and the IP, browser and open time either way. Showing the code rather than the address is deliberate — anyone reading over a shoulder learns nothing about the person holding the document, while you still get the full trail.
A static watermark is baked into the PDF file and looks identical for every reader, so a leaked page tells you nothing about who leaked it. MaiPDF’s mark is drawn live as the document opens and carries a code unique to that open, so two readers of the same file — and the same reader on two occasions — leave different marks. Nothing is written into the stored file.
No. There is no custom-text field and no style options — the watermark is a single on/off switch, and what it draws is the record number. If you need a "CONFIDENTIAL" stamp or your branding on the document, add it to the PDF yourself before uploading; MaiPDF will then show its own mark on top of yours.
Not by editing the share — Control Center has no watermark setting. The way to change it is to replace the share: upload a second PDF with the watermark set the way you want, then point the existing reading link at it. Guests do this at replace-file.html with both reading codes and both modification codes; signed-in users pick both files in Control Center. Replacing moves a whole set of settings at once, so check the second file first.
Setting the open limit above 10,000 puts the link into unlimited mode, which switches off access records — and the watermark depends on those records for its number. If you need the mark, keep the open limit at or below 10,000.
No. The watermark makes copies attributable; it does not block download or print. Pair it with SecureView if you want viewing restrictions too; the controls are independent and work together. FenceView is an older deterrent that still functions but is no longer recommended, and if the worry is screenshots rather than casual copying, the app is the only thing that actually blocks them.
This is the one case where it is the only thing that works. No software can stop a camera pointed at a monitor, but the code is on the page, so it is in the photograph too. That is why the app never lets you switch it off.
Same principle, different binding — and online it is optional while in the app it is forced. See the comparison above for what each one is tied to and where each is traced.
Watermarking is one layer of control. These guides cover the other layers that complete a secure share.
The main guide for the complete share workflow — upload, set rules, generate link and QR, track opens. Watermarking is one of several rule options you configure here.
In the app the watermark is forced on and traceable to a licence and device. This page covers the whole App DRM route, with screenshots.
Combine watermarking with open limits, expiry dates, and view mode restrictions for a multi-layer setup. That gives you more control over access and more context for later review.
QR codes for the share link itself — handy when the link has to travel onto a printed page or a slide. This is a different thing from the watermark: on links you create today the visible mark is text.
When you combine an approved email list with dynamic watermarking, the record behind each mark carries the verified email address that opened the file — the address the reader proved they control, not one they typed freely. The page itself shows only the code, but that code now resolves to a named person, which gives every reader a uniquely identifiable copy without issuing individual links.
Open MaiPDF when the visible mark should belong to the same controlled route and not act alone.
Link sharing protects the file inside the browser. The MaiPDF app goes one level deeper: a native reader asks the operating system to mark the document window as protected, so a screenshot or screen recording comes back black — with no overlay and no reading friction.
.maipdf container: the file only opens inside the app, never as a raw PDF on disk.