DEV Community: byeval

How To Auto-Detect QR Codes, Signatures, and License Plates In The Browser

byeval — Wed, 22 Apr 2026 13:51:26 +0000

One of the easiest mistakes in privacy tooling is trying to solve every target type with one detector.

QR codes, signatures, and license plates all end up as "regions to hide," but technically they are different problems:

QR codes are machine-readable symbols
license plates are structured text with strong visual constraints
signatures are image shapes more than readable words

If you force all three through generic OCR, the output gets noisy fast.

The companion guide for this piece is here:

https://happyimg.com/guides/how-to-auto-detect-qr-codes-signatures-and-license-plates-in-the-browser

Mixed detection works better than one universal pipeline

From the product side, these features all look related. The user wants the tool to suggest privacy-sensitive regions automatically.

From the engineering side, they need different signals.

The more useful architecture is:

multiple detector functions
one normalized region format
one editor surface
one review step before export

That keeps the interaction model simple without pretending the detection problem is simple.

QR codes and barcodes: use the browser when the browser already knows

For QR codes and barcodes, the cleanest path is usually BarcodeDetector when the browser supports it.

const detector = new BarcodeDetector({
  formats: ["qr_code", "code_128", "ean_13", "pdf417"],
});

const results = await detector.detect(source);

That gives you native symbol detection plus bounding boxes you can pad into safer blur or redaction regions.

The product lesson here is mostly about failure modes. If BarcodeDetector is unavailable, the UI should say so explicitly. Silent failure is worse than no feature because it makes the user trust an absence of results that may be false.

License plates: OCR is useful, but only as a candidate generator

License plates are text, but not ordinary text. A raw OCR pass usually gives too much junk unless you filter aggressively.

The pattern we used is:

start from OCR blocks and lines
normalize candidate text to uppercase alphanumeric characters
require both letters and digits
filter by plausible string length
reject impossible aspect ratios
ignore text in unlikely vertical positions

That turns OCR into a candidate generator instead of pretending it understands the full context of a vehicle image.

This is often the right level of ambition for privacy tooling: narrow heuristics on top of a broad detector.

Signatures: image analysis beats text recognition

Signatures are the opposite case. OCR often performs poorly because handwriting is inconsistent and the goal is not to read the text anyway. The goal is to find the signed region.

So the better signal was image analysis on a scaled canvas:

const imageData = context.getImageData(0, 0, canvas.width, canvas.height);
const threshold = estimateSignatureThreshold(data);

From there, the detector walks connected dark components, measures each region, and filters by heuristics like:

width
height
fill ratio
relative position on the page

Then nearby candidates can be merged into one more useful region.

This is not a universal signature model, and that is exactly the point. It is a practical heuristic for one narrow job.

Detection quality depends on what happens after detection

Even when the detector logic is correct, the raw output is usually not ready for users.

The post-processing layer matters a lot:

add padding so the target is fully covered
merge nearby fragments
deduplicate overlapping results
normalize everything into the same region shape the editor understands

If you skip those steps, the result is usually a screen full of tiny, fragmented boxes that nobody trusts.

One review model for many detectors

The biggest architecture win was not in the detectors themselves. It was in the shared output model.

Every detector returns the same kind of region object, and every region is inserted into the same editor as a reviewable overlay.

That gives the product a stable interaction model:

QR detection can suggest a region
signature detection can suggest another
plate detection can suggest blur regions
the user still reviews all of them the same way

That is much easier to maintain than building a special-case UX for every detector type.

The practical lesson

Privacy-sensitive detection gets better when you stop looking for one perfect detector and start using the right signal for each target.

The useful stack is often not:

one model
one answer

It is:

multiple detectors
narrow heuristics
normalized region output
explicit human review before export

That combination is usually much more reliable than a single generalized pass.

More implementation details:

https://happyimg.com/guides/how-to-auto-detect-qr-codes-signatures-and-license-plates-in-the-browser

Building Browser-First Image Redaction Without Uploading Files

byeval — Wed, 22 Apr 2026 13:50:54 +0000

If a redaction tool starts by uploading a sensitive screenshot to a server, the product has already created a trust problem.

That is why I think browser-first redaction is more than a frontend implementation choice. It is part of the product claim.

The companion guide for this piece is here:

https://happyimg.com/guides/how-browser-first-image-redaction-works-without-uploads

What "browser-first" should actually mean

A lot of products say they run in the browser. That statement is too vague to be useful.

For privacy-sensitive editing, the more meaningful boundary is this:

the original image stays local by default
editing happens on the client
export is rebuilt locally from the source image
the final file is downloaded directly in the browser

That does not make the implementation simpler. It just makes the privacy boundary explicit.

The visible canvas is not the source of truth

One of the first problems in a real editor is coordinate systems.

Users need a comfortable viewport with zooming and panning. The exported redaction, however, has to map back to the original image dimensions.

So the visible canvas should be treated as an interaction surface, not as the canonical image.

The implementation pattern we use is:

keep the original image dimensions as the source of truth
add the source image as the editor base layer
fit the viewport to the available screen space
keep overlays aligned to the original image coordinate system

That split is what makes browser-side editing and accurate export compatible.

Overlays are better than destructive mutations

The next decision was to treat edits as overlay objects rather than immediately mutating the bitmap every time the user interacts with the tool.

That gives the editor a much better operating model:

redaction boxes can still be moved and resized
blur and pixelation patches can react to strength changes
auto-detected regions can be replaced without touching manual edits
the user can review the exact objects that will affect the export

This is especially important in privacy tools because auto-generated suggestions should never feel permanent before review.

Export should rebuild the result, not capture the screen

Many browser image tools get loose at export time. They save the current editor state too literally, or effectively take a screenshot of the viewport.

That is not good enough for a privacy workflow.

The more reliable pattern is to create a clean export canvas at the original image dimensions, add the source image again, then replay the overlays on top of it.

In our case that starts with a fresh Fabric static canvas:

const exportCanvas = new StaticCanvas(util.createCanvasElement(), {
  width: this.sourceImageElement.width,
  height: this.sourceImageElement.height,
});

Then each visible overlay is cloned or reconstructed before generating the final file.

That matters because the editor may contain:

manual redaction shapes
blur or pixelation effect patches
auto-detected regions
text or annotation objects in adjacent tools

Export should represent the intended result, not whatever happens to be visible on a scaled viewport at that instant.

Local download is part of the privacy boundary

Once the export exists as a data URL or blob, the browser can download it directly:

const anchor = document.createElement("a");
anchor.href = dataUrl;
anchor.download = fileName;
anchor.click();

That seems basic, but in a privacy product it matters. If the editing workflow is local and the export path is local, the product story is easier to understand and easier to trust.

The hard parts are around the edges

Drawing a rectangle on a canvas is not the challenge.

The real engineering work shows up in the boundaries around the editor:

keeping original coordinates stable while the viewport zooms and pans
making auto-detection additive instead of destructive
rebuilding blur and pixelation patches accurately during export
keeping the editor responsive with large images
cleaning up canvas resources and workers on teardown

Those are the concerns that determine whether the tool feels credible.

Browser-first is a product decision

The main lesson for me was that "runs in the browser" is not the interesting sentence.

"Keeps sensitive editing local by default" is the interesting sentence.

That is the real boundary users care about, and it should shape the implementation.

If a product claims privacy-safe redaction, the architecture should reflect that claim:

local source handling
editable overlays
explicit review
local export

That will usually earn more trust than adding another server-side processing step and asking users not to worry about it.

More implementation details:

https://happyimg.com/guides/how-browser-first-image-redaction-works-without-uploads

OCR Is Not Redaction: Building Safer Auto-Redaction With Tesseract.js

byeval — Wed, 22 Apr 2026 13:49:57 +0000

OCR demos usually stop too early.

They show recognize(), print some text, and imply that automatic redaction is basically done. In a real product, that is maybe 20 percent of the job.

What users actually need is a safer pipeline:

Run OCR on the image.
Classify risky spans such as emails, phone numbers, account references, dates, and IDs.
Map those matched spans back to OCR word boxes.
Pad the boxes so the text edges are fully covered.
Insert them as editable regions instead of exporting immediately.

That is the pattern we use in a browser-first redaction flow built around Tesseract.js.

The full companion guide is here:

https://happyimg.com/guides/how-ocr-assisted-redaction-works-with-tesseract-js

Why we kept OCR in the browser

Sensitive screenshots are exactly the wrong kind of asset to upload to a server by default just to detect an email address or account number.

Running OCR in the browser gave us a cleaner privacy boundary:

the image stays local by default
the user can review the result immediately
the OCR pass can feed directly into the editor without waiting on a round trip

That still leaves the hardest part unsolved: turning OCR output into something safe enough to help with redaction.

Geometry matters more than text

For redaction, plain OCR text is not enough. The editor needs coordinates.

So instead of treating Tesseract.js as a text extractor, we ask it for structured layout data:

const result = await worker.recognize(
  asset.ocrSource,
  { rotateAuto: true },
  { blocks: true }
);

That gives us paragraphs, lines, and words with bounding boxes. Without those word-level bounds, there are no usable redaction candidates. There is only text.

We also lazily create and reuse the worker instead of rebuilding it on every scan:

if (!ocrWorkerRef.current) {
  const createWorker = await loadOcrWorkerFactory();
  ocrWorkerRef.current = await createWorker("eng", 1, { logger });
  await ocrWorkerRef.current.setParameters({
    tessedit_pageseg_mode: "11",
    preserve_interword_spaces: "1",
  });
}

That keeps the editor responsive across repeated scans and makes the OCR step feel more like a tool and less like a blocking batch job.

The useful trick: match text, then map back to words

The main implementation trick was simple and practical.

For each OCR line, we rebuild a single line string, but we also keep the character offsets of every OCR word inside that string. That gives us a bridge between pattern matching and image geometry.

So the flow becomes:

Reconstruct the OCR line as plain text.
Run regexes for categories like email, phone, URL, date, or ID.
Find which OCR words overlap each matched character range.
Merge those word bounds into one redaction region.

That lets us keep the matching logic simple while still ending up with coordinates we can draw and edit.

Tight boxes are risky

One thing that became obvious very quickly: exact glyph bounds look precise in demos, but they are risky in real privacy tooling.

If the box is too tight, the export can still leak fragments of the text around the edges. So after merging the matched word boxes, we expand the region with padding before inserting it into the editor.

That padding step ended up being one of the most important product decisions in the whole flow:

too little padding leaves readable fragments
too much padding hides useful surrounding context

So OCR quality alone is not the main issue. Region construction is just as important.

OCR should propose, not finalize

This was the biggest product lesson.

OCR-assisted redaction should not silently modify an image and export the result. It should insert reviewable regions into the editor and let the user confirm, delete, resize, or add more regions before saving.

For privacy tools, review is not a fallback. It is part of the feature.

That design also helped with the predictable OCR failure cases:

low-contrast screenshots
dense tables with tiny text
mixed-language content
broken OCR segmentation
labels like ID or Total that match patterns but are not always sensitive

Once you accept that OCR is a candidate generator instead of a perfect decision-maker, the whole interaction model gets better.

The real implementation boundary

Tesseract.js is only the OCR engine. The hard part is the boundary around it.

What actually made the feature useful was:

keeping the scan client-side
reusing the worker efficiently
preserving stable geometry
matching only the categories we cared about
padding regions conservatively
requiring review before export

That is the difference between an OCR demo and a privacy tool.

If you are building something similar, I would strongly recommend optimizing for reviewable suggestions instead of "one-click automatic redaction." The first approach ships. The second usually overpromises.

More implementation details:

https://happyimg.com/guides/how-ocr-assisted-redaction-works-with-tesseract-js