Remove Object from PDF — Smart Eraser

Scanned documents often carry something you don't want: a stray stamp, an old logo, a smudge, a signature, a watermark. Covering it with a black box is crude and obvious. The Smart Eraser tool in pdfredX removes the object and rebuilds the paper background in its place, so no trace is left. Everything happens in your browser, and the file is never uploaded.

Step 01. Load the Document

Open pdfredX and drag a PDF or scan into the upload zone. The page is rendered to Canvas locally through PDF.js — not a single byte goes to a server. Click 🖌 on the card of the page you need to open the editor.

Step 02. Select the Object With 🧹

In the editor, pick the 🧹 Smart Eraser (Healing) tool. Draw a rectangle around what you want gone: a stamp, a logo, a signature, a smudge. Leave a small margin of clean background around the object — that's where the algorithm pulls its "material" to rebuild from.

The rule is simple: the flatter and more uniform the background around the object, the cleaner the result. A stamp on a white margin is erased almost perfectly; an object over fine text or a pattern is harder.

Step 03. Tune the Pass Strength

Quality is controlled by the passes slider (fabHealPasses, 1 to 8). One pass is fast, for small objects on a flat background. More passes mean a smoother transition and less of a "seam" at the edge, but the processing takes a little longer. Start with 3 (the default) and raise it if a visible patch remains where the object was.

Don't like the result? Undo (Ctrl+Z) and try a different rectangle or pass count. The Smart Eraser reconstructs the background — it isn't perfect magic; sometimes it's better to work in two smaller passes.

Step 04. Save

Click 💾 Save — the edit is baked into the page, then Create PDF assembles the final file via jsPDF and downloads it straight from the browser. Important: on save, the page is flattened into a single image, so the original pixels under the removed object physically disappear — the object isn't "hidden under a layer," it's genuinely erased. Free, no sign-up.

How It Works Under the Hood

Under the hood is classic inpainting (image reconstruction), not a neural network. The app reads the pixels of the selected area through getImageData from lowerCanvasEl — an Uint8ClampedArray of RGBA values. For each pixel inside the rectangle, the color is computed as a weighted blend of the four edges of the selection (top, bottom, left, right): the closer the edge, the larger its contribution. Clean paper background effectively bleeds inward and covers the object.

Several passes are run (fabHealPasses): on each one, already-reconstructed pixels feed into the calculation of their neighbors, smoothing the transition. The result is written back and updates the page background (fabBgUrl) — without adding any Fabric objects, so the fix becomes part of the image itself.

Known Limitations

Complex background. The algorithm restores a uniform background well (white paper, a flat fill). Removing an object from a photo, a pattern, or fine text without a visible patch isn't always possible — there's no correct texture to pull from.

Large areas. Erasing an area larger than ~400×400 px runs on the main thread and may stutter for 0.5–1 second on a weak phone. A large object is better removed in parts.

It doesn't straighten or reconstruct content. The tool covers the object with background, it doesn't restore what was underneath. If there was text under the stamp, it won't reappear.

Rasterized output. The edit is baked into the page image. A selectable text layer on that page becomes part of the picture after saving.

If your goal isn't to remove an object with background reconstruction but to permanently hide confidential data behind a black box, that's the Redact PDF Text tool: it destroys the pixels under the rectangle.

Try it now — pdfredx.com, no sign-up, your file stays with you.

You need to remove an old stamp, someone else's signature, personal data, or a watermark from a document — and end up with a clean page. It's a sensitive job: often it's a contract, a certificate, a medical form, or an HR document. And here the path you take to clean it matters. Let's be honest about what happens to the file on a server versus in the browser.

Where the Document Goes on Server-Side Services

When you upload a PDF to a typical online editor, the file travels to a remote machine. What happens next depends on the service's policy — the one few people read:

• the file is written to a contractor's temporary storage (AWS, GCP, Azure);
• it's processed on someone else's server;
• it's retained anywhere from hours to days "for reliability";
• it's logged along with metadata — IP, timestamp, file name and size.

For a document you're specifically removing sensitive data from, this is a paradox: to erase one stamp, you first send the whole original — with that stamp and everything else — to a machine you don't control. You can't verify the copy was deleted.

Full Browser Isolation: How pdfredX Cleans a Document

pdfredX does not upload your file to any server. It's a property of the architecture you can verify.

The file is read locally. PDF.js 3.11.174 opens the document in the tab through FileReader and draws pages to Canvas. There's no network request carrying your file.

The erasure is computed in the tab's memory. The Smart Eraser is pixel operations (getImageData / putImageData) on an already-loaded image. All local, nothing sent.

The object genuinely disappears, it isn't hidden. On save, the page is flattened into a single image via toDataURL. The removed object's pixels are replaced with reconstructed background — in the exported file they're physically gone. It's not a black box on top that can be lifted off: there's nothing to recover.

PDF assembly on the client. The finished file is composed by jsPDF in the tab and handed to the browser for download — to your Downloads folder, not to a server and back.

Works offline. Open the tool, disconnect from the internet, and clean the document — everything keeps working. The network is only needed to load the app once.

Step by Step, With No Server Upload

01. Load the document. Drag the PDF into the upload zone at pdfredx.com. FileReader reads the file locally — it never leaves the device.

02. Remove the object. Click 🖌 on the page, pick the 🧹 Smart Eraser, draw around the stamp or signature, raise the pass count if needed. The object is replaced with background in the tab's memory.

03. Save and close. Click 💾 Save → Create PDF. jsPDF assembles the document locally. Once you close the tab, the file data is gone: nothing persists in sessionStorage or in memory.

What We Cannot Guarantee — An Honest Disclaimer

Client-side processing protects the document from being sent to external servers, but it isn't a shield against every threat, and claiming otherwise would be dishonest.

Malware or a keylogger already on your device. If the machine is compromised, software can read files from disk outside the browser.

Browser extensions with broad permissions. An extension with "read data on all sites" access can, in theory, see tab content. For sensitive documents, work in a profile with no third-party extensions or in a private window.

The saved file stays on your disk. If the device isn't protected by encryption, confidential files can be read by third parties with physical access.

The Smart Eraser is not forensic sanitization. It removes the visible object and its pixels from the image. But if text showed through under the removed object, or it partly overlapped important data, review the result by eye before publishing.

We provide isolation at the browser-tab level. The rest is on the user's side.

Remove stamps and signatures from documents with no server upload — pdfredx.com, free, no registration.

Removing a stamp from a scan with no seam left behind is a job in the domain of inpainting (image reconstruction). It's usually solved by heavy neural networks on a server. But for documents with a uniform paper background, a classic approach works too — edge interpolation, entirely on the client, without a single network request. Here's how the heal tool in pdfredX is built: from getImageData to the background update, with honest limits on memory.

The Architectural Challenge and the Choice of Approach

Why not a neural network. Modern inpainting models (content-aware fill) give excellent results on photos, but they're hundreds of megabytes of weights and, as a rule, server-side inference. For a web tool whose whole pitch is privacy and processing with no upload, dragging such a model into the browser is out of the question. And sending the document to a server just to remove a stamp contradicts the whole idea.

Why classic interpolation is enough. Our case isn't reconstructing a face in a photo, but removing an object from a uniform document background: white paper, a flat fill, a form. Here you don't need to "invent" texture — you just need to close the area neatly with the surrounding background color. A weighted interpolation of four edges does exactly that, and it costs almost nothing to compute.

Why on Canvas, not over the PDF structure. Scans are raster: a page is an image. PDF.js renders it into lowerCanvasEl, and from there we work directly on the pixels through the Canvas 2D API. No parsing of the PDF structure.

Algorithm Breakdown

Reading the Pixels

The starting point is the raw pixels of the area. getImageData provides them: a flat Uint8ClampedArray, 4 bytes (R, G, B, A) per pixel.

const ctx = fabCanvas.lowerCanvasEl.getContext('2d');
const img = ctx.getImageData(0, 0, W, H);
const d   = img.data;   // Uint8ClampedArray, length W*H*4

The user's selection defines a rectangle [x0, y0] … [x1, y1] — the area to fill with background.

Weighted Blend of Four Edges

For each pixel inside the selection, the color is assembled from four boundary pixels — at the intersection of its row and column with the rectangle's edges. Each edge's contribution is inversely proportional to its distance: a nearer edge "weighs" more.

for (let y = y0; y < y1; y++) {
  for (let x = x0; x < x1; x++) {
    const i = (y * W + x) * 4;

    const dl = x - x0 + 1, dr = x1 - x;      // distance to left/right edge
    const dt = y - y0 + 1, db = y1 - y;      // to top/bottom
    const wl = 1/dl, wr = 1/dr, wt = 1/dt, wb = 1/db;
    const wsum = wl + wr + wt + wb;

    for (let c = 0; c < 3; c++) {            // R, G, B
      const left  = d[(y * W + x0) * 4 + c];
      const right = d[(y * W + x1) * 4 + c];
      const top   = d[(y0 * W + x) * 4 + c];
      const bot   = d[(y1 * W + x) * 4 + c];
      d[i + c] = (left*wl + right*wr + top*wt + bot*wb) / wsum;
    }
  }
}

This is a gradient fill from four anchor points: near the edges the color almost matches the background, in the center it's an average. On flat paper, no seam is visible to the eye.

Multiple Passes

A single pass leaves a visible gradient if the area is large. So several passes are run (the fabHealPasses slider, 1–8): on each subsequent pass, the already-recomputed pixels feed into the calculation of their neighbors, and the fill "smooths out," adapting to local background irregularities. More passes mean a smoother transition but a longer compute. Three passes is a reasonable default.

Writing the Result and Updating the Background

The finished array is returned to the canvas, and the page is rebuilt into a new background:

ctx.putImageData(img, 0, 0);
fabBgUrl = fabCanvas.lowerCanvasEl.toDataURL('image/jpeg', 0.92);

The key point: the erasure updates the background image (fabBgUrl), it doesn't add a Fabric object on top. So the result can't be accidentally moved or deleted as a separate layer — it has become part of the page itself. On saveFab, everything is flattened into a single image via toDataURL({ multiplier }), and the original pixels under the area don't make it into the export.

Performance Tradeoffs and Memory Limits

The main thread. The double pixel loop runs synchronously on the main thread. For a 200×200 area at three passes that's 120,000 iterations — imperceptible. But an area larger than ~400×400 px on a weak mobile device causes a "freeze" of 0.5–1 second: the UI doesn't respond while the loop spins.

tick(16) between heavy steps. So the tab doesn't look hung, a yield to the thread is inserted between heavy operations (await tick(16) — a pause of roughly one frame). It doesn't speed up the compute, but it hands control back to the browser: the overlay gets to repaint, and the "page unresponsive" detector doesn't fire.

The cost of passes. Time grows linearly with pass count and with area. fabHealPasses = 8 on a large area is already noticeable. Hence the default of 3: a balance between seam smoothness and responsiveness.

Memory. getImageData on an area is a copy of pixels into an Uint8ClampedArray. For a local selection that's trivial; the problem isn't the erasure but the total number of page images the document holds in the tab's memory.

What We're Planning to Fix

Moving into a Web Worker via OffscreenCanvas — to remove the freeze on large areas, once Safari support stabilizes.

Accounting for background texture — right now only color is interpolated; adding light noise to match the paper texture would make the fill invisible even on a not-quite-flat background.

Auto-fitting the rectangle by object contrast — so you don't have to outline it with a margin by hand.

If you want to test it on a real scan, load a document at pdfredx.com and remove a stamp. No sign-up, no file uploads to any server.