Watermarks in Bitrix: why photo protection breaks
Automatic logo placement on a catalog breaks silently: product cards open, photos are served, but the protection on them is already gone. Most often the cause is cache.
Bitrix caches resized image copies, and when the overlay template or the logo file itself is changed, the old thumbnails remain on disk with their previous content.
The visitor receives an image from the cache, bypassing the handler, and Bitrix watermarks are simply absent in that response.
The second failure is bypassing photo protection through direct addresses. The handler is attached to output through a component, but the source files live in /upload/ and open via a direct link.
It is enough to remove the size suffix in the URL — and you get the clean original without the logo. Catalog image protection built only at the output template level is bypassed with a single address edit.
The third is quality. Overlaying on top of an already compressed thumbnail causes double re-encoding: the logo blurs, the edges of the product catalog "ring", and with repeated size generation the artifacts accumulate. If the product cards additionally go to external platforms, the degradation is immediately visible.
The fourth is manual processing. A catalog with several thousand items and several angles per product cannot be rebuilt by hand: every change of assortment or supplier means a new pass through the files, and a forgotten item remains unmarked and is discovered only after the fact.
Let's break down how this is closed: where to place the processing so that it cannot be bypassed, how to invalidate the thumbnail cache when the logo changes, and how to rebuild the marks across the entire catalog without losing quality.
Overlay Modes and Formats: What to Choose for the Task
Where to Apply the Mark: on Upload or on Delivery
Processing on upload — the mark is baked into the file once, and then the ready image is served. The downside is that the original without the mark has to be stored separately, otherwise re-generation is impossible.
Overlaying on delivery leaves the source files untouched, but every request goes through the handler: without image caching, this adds a noticeable delay on galleries with hundreds of photos.
The practical approach is a hybrid: the mark is applied on upload, and the result is placed in a separate directory with a size suffix. Re-generation when the logo changes is done in batches from the source files, without editors re-uploading files.
Overlay Mode and Transparency
The watermark overlay mode determines how the logo sits on the background. Multiply and Darken are readable on light backgrounds but disappear on dark areas; Screen and Lighten work the opposite way.
Normal with semi-transparency is the most predictable option: logo transparency in the 40–60% range keeps the mark readable and does not kill the details of the photo underneath.
For PNG with an alpha channel, transparency is set in the file itself; for JPEG, it is set by the overlay parameter. You cannot mix them: JPEG does not store alpha, and the mark will get a white rectangle around its edges.
Mark Storage Format
| Option | When it fits | Limitations |
|---|---|---|
| PNG with alpha | Logo with a complex shape, shadow, smoothed edges | File weight is higher than JPEG |
| SVG | Vector mark, need different sizes without loss of sharpness | Not all processing libraries read SVG directly |
| JPEG | Dense mark without transparent zones | No alpha channel, visible frame on a colored background |
| WebP with alpha | Need both low weight and transparency | Requires checking support on the delivery side |
Cache and Re-generation
Image caching is built on a key: the source file plus a hash of the mark parameters — position, transparency, mode. Changing the logo changes the hash, old previews are invalidated automatically instead of lingering in the directory.
This removes the classic problem of "the mark was updated, but the old one is still on the site": rebuilding runs on a schedule, without manually going through galleries.
1C-Bitrix serves ready previews through its own resize mechanism — it is important that the mark is applied before writing to the cache, otherwise it will either not appear or will be applied again on every request.
Step-by-step implementation: from catalog audit to handover
Implementation of automatic mark placement begins with an audit of the catalog images: we count the total volume, the share of products without a main photo, the spread of sizes and formats, the presence of duplicates and files already marked manually.
At this stage it becomes clear where the scheme will fail — for example, on images with transparency or on narrow cards where the mark will cover the product itself. Without an inventory, any processing setup runs into manual trial and error and re-uploading.
Next, we design the mark overlay scheme: position, offset from the edge, scaling relative to the image width, opacity, and behavior on light and dark backgrounds.
We lock down the scheme before writing code — otherwise "by eye" edits after launch break cards that have already been processed.
- Catalog image audit — exporting the file list, measuring sizes and formats, finding duplicates and files already marked manually.
- Approval of the overlay scheme — position, offset, scale, opacity, separate rules for light and dark backgrounds.
- Processing setup — binding to product upload and update events so the mark is placed automatically rather than through a batch run.
- Test run on a sample — 50–100 real cards from different categories, including problematic ones: transparency, panoramas, small photos.
- Result verification — comparing the output against the reference, checking that the mark does not cover the product and is not duplicated on re-upload.
- Mass processing of the remainder — a run across the entire catalog with a log of processed and skipped files.
- Handover with documentation — a description of the scheme, binding points, and rollback procedure so that edits can be made without us.
Verification on real cards is a mandatory step: it is there that categories surface where the standard scheme does not work, and separate rules are defined for them. After handover, the client receives a working mechanism and documentation that can be used to develop it further. Describe your task — we will come back with an estimate and a plan.
How is on-upload watermarking different from batch processing?
On-upload watermarking triggers the moment a file enters the media library or is attached to an infoblock element. The handler receives the original, overlays the mark at the specified position and opacity, and the already-marked image then goes into storage.
From there, thumbnails are generated — meaning all derived sizes immediately contain the mark, and they don't need to be touched separately.
This path closes the issue for new content: an editor uploads a photo — it's already protected, with no manual actions and no risk that someone forgets to enable a checkbox.
Batch image processing works differently: it goes through files already sitting in the system and overlays the mark on top of existing images. This is the only way to cover an existing catalog where thousands of photos have accumulated without protection.
The run proceeds in batches to avoid consuming server resources and blocking the site for visitors; after processing, thumbnails must be rebuilt — otherwise product cards and feeds will retain old copies without the mark, and the protection will appear to work only in the admin panel.
The key limitation of the batch path is irreversibility. The mark is burned into the pixels, and the original can only be restored from a backup, if one was taken before the run.
Therefore the order is: first a storage copy, then a run on a test environment, then the production run.
On-upload watermarking lacks this drawback — there too the original is overwritten, but the scope of changes is limited to a single file, and a rollback doesn't require restoring the entire catalog.
The second difference is behavior when the mark's layout changes. If the logo, position, or opacity is changed, on-upload watermarking will apply this only to new files, while old ones will keep the old mark.
A batch run in such a situation is the standard tool: it re-covers the entire array with a single layout.
In practice, these two paths don't compete but complement each other: batch processing aligns what has accumulated, while on-upload watermarking holds the bar for everything that comes afterward.
The third point is performance. A batch run over a large catalog takes hours and requires a maintenance window, whereas on-upload watermarking adds fractions of a second to the request and is unnoticeable to the editor.
Hence the working scheme: a one-time batch pass over the archive, then continuous processing at the input.
Case study: how a catalog stopped losing photos when copied
The client — a retail chain with a catalog of several thousand items — came with a specific pain point: competitors regularly scraped product cards along with their photos.
Some products had no in-house shots, and the source files were publicly accessible on the server — all you had to do was open the image URL and save the file.
Over a quarter, 40+ image matches were recorded on third-party sites, and manually processing the catalog was not feasible: managers could only protect about 15% of new arrivals in time.
What was changed
We moved watermarking into the upload pipeline: as soon as a product is saved to the info catalog, the image is processed automatically — the logo is overlaid at a specified position with adjustable transparency, and the source file goes into private storage.
Only the protected version is served publicly, so downloading via a direct link no longer yields a clean image.
Processing was moved into background jobs with a queue: a batch of 500 images completes in 6-8 minutes without blocking administrators' work.
For each product card, an "original — protected copy" link is preserved, so when the logo or its position changes, rebuilding uses the existing source files, with no re-uploading.
Metrics before and after
| Metric | Before | After |
|---|---|---|
| Share of protected cards | ~15%, manually | 100% automatically |
| Processing time for a batch of 500 photos | several days of manual work | 6-8 minutes in the queue |
| Incidents with exposed source files | 40+ per quarter | class closed: no public originals |
| Rebuilding when the logo changes | re-uploading all photos | from the preserved source files |
Integrity was addressed separately: if processing fails midway through a batch, the job restarts from the last successfully processed image, and a product card without a protected copy is not published — a visitor will not see a product with a "hole" instead of a photo.
The pipeline was built on the platform's built-in image processing tools — no external services and no sending files to third parties.
The overlay logic is described declaratively, so adding a new type of mark (for example, for a promo section) takes a configuration edit rather than rewriting code.
1C-Bitrix in this scenario provides ready-made extension points on catalog events — that was enough to embed processing into the existing upload process without touching the admin panel.
Doubts before starting: compatibility, rollback, access
Before enabling automatic watermarking in Bitrix, the most common questions are about compatibility with the current template: will the layout break, will the catalog output fail.
Image processing is hooked into upload and resize events, not into the template, so the markup and components remain untouched — only the contents of the file on disk change. If the project has its own resize handlers, we first check their priority to avoid double overlay.
What if a rollback is needed? All changes are packaged as a separate module and enabled via a setting, not by editing the core. Disabling restores the original upload behavior in one step, without untangling third-party code edits.
Before deployment, we make a backup of the database and file storage — rollback is possible at any point.
What access is needed? Access to the administrative panel and to the server for the duration of the work is sufficient: file system, scheduler, access to image storage.
If direct access cannot be granted, we work through agreed windows and hand over commands for your administrator.
What happens to already uploaded images?
Existing files are processed in a separate pass over the storage with load throttling — it can be run in batches during off-hours. New uploads pick up the rule immediately, so no mixed state remains in the catalog.
The customer receives:
- module configuration with a description of all parameters;
- a diagram of the image flow from upload to delivery;
- overlay policy: position, transparency, behavior on previews;
- rollback and re-enable instructions;
- backup procedure before changes;
- description of the access rights needed for operation and support.
Describe your task and current template — we will get back to you with an estimate and work plan, including the deployment order and rollback points.