How to Automatically Watermark Images on Upload (Without a Batch Job)

If you already run your own upload backend, watermarking is one compositing step: ImageMagick on the command line, or sharp's composite() if the pipeline is Node. The software is free and the control is total: any placement, any opacity, tiled or single, a different mark per output size. What you're paying with is everything around that step. You own the upload endpoint itself, a queue so 400 wedding photos arriving at once don't stall the web process, EXIF orientation handling so portrait shots don't get stamped sideways, and HEIC conversion for whatever an iPhone decides to send. If that pipeline already exists, adding the watermark is an afternoon. If it doesn't, the watermark is the easy five percent of the project.

Transformation CDNs like Cloudinary treat the watermark as a URL parameter: you store the original once, and an overlay layer in the delivery URL applies the mark per request. It's the most flexible model, because one original can serve a heavily marked proof and a clean print file from two different URLs. It's also the model where protection depends on configuration discipline: the clean original lives on the CDN, and any URL without the overlay parameters serves it, unless you've also enabled strict transformations or signed URLs. Plenty of teams get that right. Some find out they didn't when a client notices that deleting half the URL removes the watermark.

Ingest-time watermarking flips the order of operations: the mark is burned in while the file is being processed at upload, and what lands in storage is already stamped. Nothing to remember per shoot, and no URL variant that serves the file clean. The tradeoff is that burned-in means burned-in: when you need an unmarked copy later, you upload it through an endpoint that doesn't watermark; you don't peel the mark off. That's the model Tonta runs, and it's the working example for the rest of this guide.

The only watermark that shows up on every image is the one nobody has to remember to apply.

• Design a mark that survives a crop. Semi-transparent, large enough that removing it costs real effort, and placed across the subject rather than tucked in a corner. A corner mark disappears in one crop; that's why every proofing service you've ever seen puts it across the middle.
• Create an uploader and turn watermarking on. In the Tonta dashboard, each uploader is its own endpoint with its own settings. Enable the watermark on the one that handles proofs or previews. Watermarking is available from the Starter plan at $9 a month.
• Embed the uploader where images come in. One script tag pointed at a target element, shown below. If the surrounding form doesn't exist yet, the walkthrough on how to add file upload to your website covers that end to end.
• Test with a real photo. Upload a full-resolution shot and inspect the versions in the JSON response. The stamped, resized, WebP output is what you serve; if the mark is too faint at web size, adjust it now, not after a gallery ships.
• Turn on XMP if attribution matters. Creator and copyright fields get written into the file itself. It needs enabling in the dashboard; it isn't on by default.

The embed is the whole integration. It renders the upload UI and posts the file to Tonta's hardened endpoint, so there's no backend to write and no processing queue to run:

<script src="https://tonta.io/uploader/uploader.js"
        data-backend="https://tonta.io/uploader/upload.php"
        data-target=".proof-uploader"
        data-api-key="YOUR_API_KEY"
        data-callback="handleUpload"></script>

If you're weighing this style of drop-in embed against building your own front end, the file upload widget comparison goes through that fork properly. And for photographers, the useful next move is that any Tonta uploader can be flipped into a shareable gallery: proofs go in watermarked, clients browse them from a link, nobody installs anything. The reverse direction, getting raw files from clients in the first place, is a different setup with its own pitfalls, covered in the guide to collecting files from clients.

The free tier is a real one, 5 GB and one uploader with no card required, and it's the right place to prove the pipeline before paying: uploads, resize, WebP, the JSON response, all of it works at $0. The watermark itself is a Starter feature, and $9 a month buys a sensible bundle for a working photographer or a small product team: 100 GB, the mark applied automatically, and the uploader wearing your branding instead of Tonta's. Five uploaders also map cleanly onto a proofing workflow: one watermarked endpoint for previews, one clean endpoint for final delivery after payment, and room left over.

Two limits worth stating plainly. Watermarking on Tonta is an image feature; video upload with GPU transcoding exists from Professional up, but a burned-in video watermark isn't a documented capability, so ask before you build a plan around it. And there's no official SDK: integration is the script tag plus plain HTTP, which covers most sites fine, but a team that wants a first-class Python or Ruby client won't find one today.

If images only ever leave your machine through Lightroom exports, Lightroom's built-in watermark on an export preset is automatic enough, and you already paid for it. It stops working the moment uploads start happening from other people and other devices, but a solo shooter with one laptop and one workflow doesn't need an upload pipeline to solve a problem they don't have.

If you need many different marks from one original, a partner logo for one channel, a heavy proof stamp for another, a clean file for print, Cloudinary's on-request overlays genuinely win: one stored original, every variant a URL. You take on a bigger platform, metered transformations, and the strict-transformations homework from earlier, but for multi-variant delivery at scale that's the better fit.

And if you already operate an upload backend you're happy with, bolting a composite step onto it is a small, honest job. The at-upload model earns its keep the moment more than one person, device, or workflow feeds images into the same place. That's the point where "remember the preset" stops being a plan.