# OCR With Stamps, Watermarks and Highlighter: Tested

> Tinted backgrounds cost OCR nothing, highlighter and grids did. We tested 20 stamp, watermark and background cases and a cleaning script that fixed 17.

**In short:** In Tesseract 5.5.2 tests on 24 invoice pages and 20 conditions, tinted and dark gray backgrounds cost 0.0% error, while highlighter behind two of six lines cost 33.6%, a dark gray watermark 24.7%, a ruled grid 54.7% and a blue stamp 16.4%. Taking the brightest color channel removed red and blue stamps (to 0.0%), a darkness cutoff removed the watermark, and removing long lines cut the grid to 3.6%. A black stamp over text could not be fixed (7.5% to 9.3%). Includes a tested cleaning script that scored 0.0% on 17 of 20 conditions.

**Canonical URL:** https://docsapi.co/resources/blogs/ocr-stamps-watermarks-highlighter
**Author:** Nupura Ughade — Content Marketing Lead, DocsAPI
**Author LinkedIn:** https://www.linkedin.com/in/nupura-ughade/
**Published:** 2026-11-09T00:00:00.000Z
**Updated:** November 9, 2026
**Primary topic:** ocr stamps watermarks
**Site:** https://docsapi.co (DocsAPI — Document AI & OCR API for SMB Lending)

---

Most things that make a page look messy do not hurt OCR. Some do, badly. In our tests with Tesseract 5.5.2 on 24 invoice pages and 20 conditions, tinted and even dark gray backgrounds cost nothing (0.0% character error), while yellow or pink highlighter behind two of six lines cost about two lines' worth of text (33.6% error), a gray watermark at the wrong darkness cost 24.7%, a table grid drawn across the text cost 54.7%, and a blue rubber stamp cost 16.4%. A short cleaning step brought almost all of that back to 0.0%. A black stamp printed over text is the one thing it could not fix.

This guide shows the numbers for each case, which cleanup works for which problem, and a short script that we ran on every condition. It also corrects a common assumption. Some guides to OCR failures put colored backgrounds near the top of the causes. In our test the background color was the least of the problems; what mattered was ink that overlapped the text, and highlighter.

## How did we test stamps, watermarks and backgrounds?

We took 24 synthetic English invoice pages (six lines each, 300 DPI, black text on white) and added one problem at a time: 18 conditions, each applied to the same 24 pages, and later two darker backgrounds. Stamps were drawn as rotated text with a heavy border and blended into the page the way ink does, so the text underneath still shows through: a red "PAID", a blue "RECEIVED 12 MAR 2024" and a black "COPY", each placed across two or three lines of text. Watermarks were a large diagonal "CONFIDENTIAL" in four shades of gray. Backgrounds were flat tints (yellow, blue, and gray at 170 and 110 out of 255, then 90 and 70). We also added yellow and pink highlighter bars behind two of the lines, lines under each text line, a grid of ruled lines through the text, a wavy security-paper pattern, and one page with a red stamp, a gray watermark, a highlighted line and a grid all at once.

Each page was read with Tesseract 5.5.2 and the English model in single-block mode (`--psm 6`), and we measured characters wrong divided by characters expected, spaces ignored, as defined in [how to measure OCR accuracy](/resources/blogs/how-to-measure-ocr-accuracy). We compared eight ways of preparing the page: no help, no help in the default page mode, grayscale with Otsu thresholding, the brightest color channel with Otsu, background flattening with Otsu, flattening plus brightest channel plus line removal, a fixed darkness cutoff, and the cutoff plus line removal. The 18 conditions with eight methods make 3,456 reads. A further 1,440 reads covered all 20 conditions (with the two dark backgrounds) for no help, a fixed cutoff and the final script, for about 4,900 reads in total. The page images are clean renders, which is the main limit, covered near the end.

## Which of these problems actually hurt OCR?

Highlighter, grids, strong watermarks and colored stamps hurt. Tinted backgrounds, underlines and pale watermarks did not. The table shows character error when the page is read as it is, and again after the cleaning script in this guide.

| What is on the page | Read as it is | After cleaning |
| --- | --- | --- |
| Nothing (clean page) | 0.0% | 0.0% |
| Red "PAID" stamp over the text | 5.8% | 0.0% |
| Blue "RECEIVED" stamp over the text | 16.4% | 0.0% |
| Black "COPY" stamp over the text | 7.5% | 9.3% |
| Gray watermark, very pale (235 of 255) | 0.0% | 0.0% |
| Gray watermark, pale (215) | 0.0% | 0.0% |
| Gray watermark, medium (180) | 1.3% | 0.0% |
| Gray watermark, dark (140) | 24.7% | 0.0% |
| Tinted background: yellow, blue, gray 170, 110, 90 or 70 | 0.0% each | 0.0% each |
| Yellow or pink highlighter behind two lines | 33.6% each | 0.0% each |
| Lines under each text line | 0.0% | 0.0% |
| Grid of ruled lines through the text | 54.7% | 3.6% |
| Wavy security-paper pattern | 2.3% | 0.0% |
| Red stamp, watermark, highlighter and grid together | 61.8% | 3.5% |

The tinted backgrounds are the surprise. Even black text on a dark gray page (70 of 255) read with no errors at all, so a colored background on its own is not what breaks OCR in a clean scan. We would expect low-contrast text, gray on gray or pale print on color, to be a different story, but we did not test it. What broke the read in our pages was anything that was dark and overlapped the letters, plus one thing that was neither: highlighter.

The default page mode made the stamps worse. In the same read with `--psm 3`, the red stamp cost 12.4%, the blue stamp 21.3% and the black stamp 24.9%, against 5.8%, 16.4% and 7.5% in single-block mode. If you read stamped pages, check which page mode you use before you blame the stamp.

## Why does a highlighter make lines disappear?

We do not know, but the effect is clear. With yellow or pink bars behind two of the six lines, the read scored 33.6% error, which is about the share two lines out of six would give, and the default page mode scored the same. Converting the page to grayscale and thresholding it ourselves brought it to 0.0% for both colors, so the text was legible; Tesseract's own handling of the color image lost it. Our guess, untested, is that the engine's built-in thresholding treats the colored bar as a separate region.

The lesson is practical. If your documents have highlighter, do not hand the color image straight to the engine. Convert to grayscale and threshold first. Every method in the next table that did this scored 0.0% on both highlighter colors.

## Can you remove a colored stamp before OCR?

Yes, if the stamp is not black. Take the brightest of the three color channels for each pixel, instead of the usual grayscale mix. Black text is dark in all three channels and stays dark. Red, blue, yellow and pink ink are bright in at least one channel, so they turn light. On our pages, this took the red stamp from 5.8% to 0.0% and the blue stamp from 16.4% to 0.0%.

| Condition | No help | Default page mode | Gray + Otsu | Brightest channel + Otsu | Flatten + Otsu | Flatten + brightest + Otsu + lines | Cutoff 100 | Cutoff 100 + lines |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Red stamp | 5.8% | 12.4% | 7.0% | 0.0% | 6.9% | 0.0% | 0.0% | 0.0% |
| Blue stamp | 16.4% | 21.3% | 17.8% | 0.0% | 17.8% | 0.0% | 0.0% | 0.0% |
| Black stamp | 7.5% | 24.9% | 8.4% | 8.4% | 8.4% | 9.6% | 8.6% | 9.4% |
| Dark watermark (140) | 24.7% | 32.1% | 26.1% | 26.1% | 27.1% | 34.8% | 0.0% | 0.0% |
| Highlighter (yellow) | 33.6% | 33.6% | 0.0% | 0.0% | 0.0% | 0.0% | 0.0% | 0.0% |
| Ruled grid | 54.7% | 38.9% | 54.7% | 54.7% | 54.7% | 4.1% | 53.1% | 3.6% |
| Everything at once | 61.8% | 52.1% | 26.1% | 53.4% | 29.0% | 3.9% | 53.4% | 3.5% |

Every cell averages 24 pages. Two things stand out. First, the plain grayscale and the flatten methods did nothing for the colored stamps (7.0% and 6.9% on red, against 5.8% unprocessed), because converting color to gray keeps the stamp fairly dark. Second, the black stamp stayed at 8.4% to 9.6% under every method. When the ink that covers the text is the same color as the text, there is nothing to separate on color or on darkness, and cleaning slightly raised the error (7.5% to 9.3%). That needs a different tool, such as a layout step or a model that reads through the overlap. Our guide to [proof of delivery processing](/resources/blogs/proof-of-delivery-processing) covers stamped reference numbers on delivery documents.

## What does a gray watermark cost, and what fixes it?

Pale watermarks are harmless and dark ones are not, and the usual thresholding methods do not help. A "CONFIDENTIAL" watermark at 235 or 215 out of 255 cost nothing, at 180 it cost 1.3%, and at 140 it cost 24.7% unprocessed. Otsu thresholding, with or without flattening the background, left it at 26.1% to 27.1%, and flattening plus line removal made it worse, at 34.8%.

A fixed darkness cutoff fixed it: keep only pixels darker than 100 out of 255, and the 140 watermark vanished (24.7% to 0.0%) while the black text stayed. Our explanation, which we did not test, is that Otsu picks its threshold from the shade mix on the page, and a large mid-gray watermark pulls that threshold toward the watermark. A fixed cutoff does not move. That only works if the text is darker than the watermark by a clear margin. A watermark darker than about 100 would be treated as text, and a page of pale gray text would vanish.

The cutoff has a second trap, which is the page itself. A fixed cutoff of 100 turned a dark gray page (background 90 or 70) entirely black, and the read returned 100% error. Setting the cutoff from the page's own brightness, half the median pixel value up to a maximum of 100, fixed that: 0.0% on both dark backgrounds. The script below does this.

## How do you handle table lines and grids?

Remove long thin lines from the page after thresholding. Lines drawn under each text line cost nothing, which is why a lined invoice usually reads fine. A grid whose lines cross the letters is a different matter: it cost 54.7% unprocessed, and the default page mode did only a little better at 38.9%. Removing every horizontal or vertical run longer than 0.4 inch (120 pixels at 300 DPI) brought the grid page to 3.6%, and the combined page to 3.5%.

The residual 3.6% is the cost of that method. Taking out a line that passes through the middle of a letter takes some of the letter's strokes with it, and we think that is the likely source of the remaining errors, though we did not trace them. If your tables carry text that sits right on the lines, the better answer is to find the table structure first and read cell by cell, which our guide to [layout analysis and key-value extraction](/resources/blogs/ocr-layout-analysis-and-key-value-extraction) covers with its own tests.

## What is the workflow, and can I run it?

Fix the orientation, clean the page with the script below, then read it. Orientation comes first: our tests of [upside-down and sideways pages](/resources/blogs/ocr-upside-down-sideways-pages) show that a page turned the wrong way fails regardless of cleaning. After cleaning, read the page with `--psm 6` or whichever mode suits your layout, and check the figures as in [fixing OCR errors in numbers and IDs](/resources/blogs/how-to-fix-ocr-errors). The script needs `opencv-python` and `numpy`.

```
#!/usr/bin/env python3 """Clean a scanned page before OCR: drop colored stamps and highlighter, gray watermarks and ruled lines. Steps: 1. Take the brightest of the three color channels per pixel. Black text stays dark; red, blue, yellow or pink ink and highlighter turn light. 2. Keep only pixels darker than a cutoff set from the page's own paper brightness (at most 100 out of 255). Gray watermarks and tinted backgrounds fall above it and turn white. 3. Remove long thin horizontal and vertical runs (ruled lines and table grids). A black stamp printed over text cannot be separated this way. Usage: python3 clean_page.py in.png out.png [dpi] then: tesseract out.png stdout --psm 6 --dpi 300 Needs: opencv-python and numpy. """ import sys import cv2 import numpy as np def clean(src, dst, dpi=300): img = cv2.imread(src, cv2.IMREAD_COLOR) page = img.max(axis=2) cutoff = min(100, 0.5 * float(np.median(page))) ink = (page  3 else 300)
```

We ran it on all 20 conditions, 24 pages each. It scored 0.0% on 17 of them, including all six tinted backgrounds, both highlighter colors, the red and blue stamps and every watermark. The three that stayed above zero were the ruled grid (3.6%), the combined page (3.5%) and the black stamp (9.3%). The same pipeline with a fixed cutoff of 100 and no adjustment for page brightness scored within a tenth of a point of the script on every condition except the two dark backgrounds, where it returned 100% error, so the brightness rule is not optional.

A caution on scope. The script suits scans of mostly white paper with dark print. It is a poor fit for photographs with uneven lighting or shadows, where a single cutoff across the page will lose text in the dark corners, and for documents printed in light gray ink. For old faxes with speckle, the median and despeckle steps in [our fax cleaning tests](/resources/blogs/convert-fax-tiff-jpg-png-to-text) are the better starting point.

## What do these tests not show?

Eight limits. First, the pages are clean renders with ideal black text, and real scans add noise, JPEG artifacts, uneven lighting and fading, which will make every number here worse. Second, our stamps and watermarks are drawn and blended by us. Real stamps vary in ink density, bleed through paper and sometimes blot the text, and a faded red stamp may be darker or lighter than ours. Third, we used one typeface and one text size, about 11 points. Fourth, we tested only English and only Tesseract; other engines handle color and overlap differently, and we did not test DocsAPI on these conditions.

Fifth, the stamps and watermarks sat in the same place on every page. Sixth, we did not test colored text on colored backgrounds, gray text, or reversed text, which are the cases where background color probably does matter. Seventh, we measured characters, not fields: a few wrong characters can still ruin a total or an invoice number, and our [tests of DPI, tilt and blur](/resources/blogs/how-does-ocr-work) show how quickly clean-page accuracy falls once a scan degrades. Eighth, the cleaning script has parameters (the cutoff, the line length) we chose by hand, and we did not tune them. What we trust is the pattern: ink that overlaps the text is the problem, tints are not, and a few lines of preprocessing recover most of it.

## Where does DocsAPI fit?

DocsAPI is not built on a single OCR engine. It uses a layout-aware proprietary engine with a vision-language model fallback for complex cases, and it extracts fields and tables, runs document checks, and flags low-confidence fields for a person to review. It was built by HyperVerge. In DocsAPI's own 2026 benchmark of 1,700 documents it scored 97 to 99% on clean typed text, 91% on multi-page bank statement tables and 76% on phone-photographed receipts. Those figures come from that benchmark, not from the Tesseract tests in this guide, and we did not run the stamp, watermark or highlighter tests on DocsAPI, so we make no claim about how it behaves on them.

DocsAPI is available as a demo, then a free 30-day trial for qualified lenders. Pricing starts from $0.02 per page, with volume discounts above 100,000 pages a month. If your intake includes stamped or watermarked pages, collect 30 of the worst ones, read them as they are, and count the wrong figures and the pages that return a clean-looking wrong answer without a flag. The method behind the benchmark figures is in the [2026 accuracy benchmark](/resources/blogs/ocr-accuracy-benchmark-2026).

## Sources and how we checked this

All figures come from our own runs on 9 November 2026 with Tesseract 5.5.2: 24 synthetic English pages, 18 conditions read with eight preparation methods (3,456 reads), then 20 conditions (adding two dark backgrounds) read three ways (1,440 reads). Every table was computed from the raw per-page results, and the script in this guide is the file we ran. An earlier version of the cutoff used a fixed value of 100 with no adjustment for page brightness; it failed on the two dark backgrounds, which is why the final script scales the cutoff and why we report that failure above.

## Frequently Asked Questions

### Do colored backgrounds break OCR?

Not in our test. Black text on yellow, blue and gray backgrounds (down to 70 out of 255) read with 0.0% character error in Tesseract 5.5.2. Low-contrast text on color is a different case that we did not test. Overlapping ink and highlighter did the damage instead.

### Does a watermark affect OCR accuracy?

It depends on the shade. A gray CONFIDENTIAL watermark at 235 or 215 out of 255 cost 0.0%, at 180 it cost 1.3%, and at 140 it cost 24.7%. Otsu thresholding did not fix the dark one, but a fixed darkness cutoff of 100 brought it to 0.0%.

### How do you remove a stamp before OCR?

For a red, blue or other colored stamp, take the brightest of the three color channels per pixel. Black text stays dark and the colored ink turns light. On our pages this took a red stamp from 5.8% to 0.0% and a blue stamp from 16.4% to 0.0%. A black stamp over the text cannot be removed this way.

### Why does OCR miss highlighted text?

We do not know the cause, but in our test yellow or pink highlighter behind two of six lines cost 33.6% character error when the color page was read directly. Converting the page to grayscale and thresholding it first brought the error to 0.0% for both colors.

### Can OCR read text under a black stamp?

Poorly. A black COPY stamp over the text cost 7.5% error, and every cleaning method we tried left it between 8.4% and 9.6%, because the stamp and the text are the same color. In the default page mode the error was 24.9%.

### How do you remove table lines before OCR?

Threshold the page, then delete horizontal and vertical runs longer than about 0.4 inch (120 pixels at 300 DPI). This cut a ruled-grid page from 54.7% to 3.6% error. Lines drawn under the text lines cost nothing, so only grids that cross the letters need this.

### What cutoff removes a gray watermark?

Keep only pixels darker than about 100 out of 255, but set the cutoff from the page's own brightness (half the median, up to 100). A fixed 100 removed the 140 watermark but turned dark gray pages (background 90 or 70) fully black and returned 100% error.

### Should I clean pages before OCR?

Only when the page has overlapping ink, highlighter, a dark watermark or a grid. On clean pages and on tinted backgrounds, cleaning changed nothing in our test. The script in this guide scored 0.0% on 17 of 20 conditions and is a poor fit for photos with uneven lighting.


---

**Source URL (cite this):** https://docsapi.co/resources/blogs/ocr-stamps-watermarks-highlighter
**Author profile:** https://docsapi.co/author/nupura-ughade
**Published by:** DocsAPI (https://docsapi.co)