The Remove Images from PDF tool is a browser-based utility that replaces every eligible embedded JPG inside a PDF with a 1×1 white JPEG, leaving each page's drawing command and resource reference intact so the rewritten file still loads cleanly when reopened. It does so without uploading your document to a server: the inspection, the swap, the structural check, and the final download all happen inside one browser tab. For anyone searching "how to remove image from pdf nitro," that difference is the whole point of switching tools. Nitro Pro's Whiteout tool draws an opaque shape on top of a region. The original image bytes stay in the file, simply hidden from the eye. The browser tool does something sterner: it walks every image XObject referenced by the page content stream and rewrites the image payload itself, so the original bytes are no longer used for any visible page even if the file is reopened in Nitro and someone unchecks the Whiteout rectangle later.
That distinction matters whenever the goal is more than a cosmetic cover-up. A PDF prepared for external sharing, a draft that needs lighter inline graphics, or a scan-based document where the embedded photo should not travel with the file all benefit from object-level replacement rather than layered painting. The rest of this article walks through the practicalities: how the tool decides what counts as eligible, exactly how to run it, which page elements survive the swap untouched, and where the method stops being the right one.
Why Nitro's Whiteout Covers but Doesn't Remove
Nitro's documentation describes the Whiteout tool as a way to "securely obscure content in PDF documents" with the same finality as physical correction fluid: "when a section of the document is covered with whiteout, the action cannot be undone." That language is accurate for visual obscuring, but it stops short of what most users mean by "remove an image from a PDF." Whiteout paints a vector rectangle or raster patch over the image area; the underlying image XObject is still listed in the page's resources and still contributes to the file's serialized size.
Three consequences show up in real workflows:
- The PDF still ships the original image bytes to anyone who receives the file. A recipient who opens the PDF in a viewer that supports object-level inspection, or in a tool that ignores whiteout layers, can extract the covered photo.
- File size barely changes, because the swap is purely a layer in the page tree rather than a change to the resource dictionary.
- Removing the Whiteout rectangle in Nitro brings the original image back unchanged, which is the opposite behaviour from an image-stripped copy.
The Italian edition of the same Nitro user guide describes Whiteout as a way to "eliminare in modo sicuro selezioni di testo, immagini" — securely delete selected text and images. The English phrasing is "securely obscure," and that single word is the giveaway. Obscure means cover up, not extract.
How the Local Image Strip Works
Remove Images from PDF runs entirely inside the browser. The PDF you select never leaves your device: no upload, no server-side edit, no account. Once the file is loaded, the tool iterates over every indirect image XObject the PDF declares and asks one eligibility question per object — is this an unmasked 8-bit DCTDecode JPEG using DeviceRGB or DeviceGray, with no DecodeParms dictionary?
The eligibility bar is strict on purpose. The implementation replaces each eligible image stream with a hand-built 1×1 white JPEG and then writes that stream back into the original indirect object's slot, using a PDFRawStream from the pdf-lib library. Page drawing commands that referenced the image by name still resolve to a valid object after the rewrite, so the page tree, page geometry, text layer, link annotations, and any non-image vector content are unaffected.
Two structural checks run after the new PDF is saved back to your device. The first uses pdf-lib itself to reopen the file and confirm the page count and the expected count of replaced image objects. The second uses PDF.js, the same viewer engine used by major browsers, to render the result and prove the file still loads cleanly. If either check disagrees with the pre-save state, no download button is shown.
The all-or-nothing rule on eligibility is what makes the workflow safe. If your PDF contains even one image using a different filter, a soft mask, an indexed palette, CMYK, JPEG 2000 (JPX), JBIG2, LZW, FlateDecode, or any other encoding the tool does not handle, the entire job is refused before any output is produced. That decision avoids the worst-case bug for image stripping: a downloaded PDF whose button promises images were removed while a complex image was silently left in place.
Stripping Embedded JPGs From Your PDF
The actual sequence in the browser is short on purpose. Run it on a copy of the document, not the only copy, until you have confirmed the output behaves the way your workflow needs.
- Choose one local PDF up to 25 MB. Encrypted, malformed, signed, or unusual PDFs may be rejected by the safety rules before any swap begins, and supported input is limited to a single local PDF up to 25 MB.
- Select "Remove eligible images" to run the all-or-nothing compatibility check. The browser enumerates every image XObject and decides whether the whole file passes the strict eligibility rule. If even one image fails, no output is offered.
- Inspect the new PDF, then download it only after confirming the white replacements are appropriate. Open the result in your usual viewer — Nitro Pro, Acrobat, your browser's PDF viewer — and check pages, text, links, and page geometry before treating the file as final.
The deliberate friction at step three is the safeguard. Because the tool refuses unsupported encodings rather than guessing, the inspection step is where you decide whether the white-pixel outcome fits the document's purpose.
What Counts as an Eligible Image
The eligibility table below describes the categories the tool recognises. Anything outside these rows turns the whole job into a refusal rather than a partial success.
| Embedded image characteristic | Outcome |
|---|---|
| Unmasked 8-bit DCTDecode JPEG in DeviceRGB | Eligible — replaced with 1×1 white JPEG |
| Unmasked 8-bit DCTDecode JPEG in DeviceGray | Eligible — replaced with 1×1 white JPEG |
| Image carries a soft mask or stencil mask | Refused — whole job stops |
| Indexed (palette) color space | Refused — whole job stops |
| CMYK JPEG | Refused — whole job stops |
| JPEG 2000 (JPXDecode) | Refused — whole job stops |
| JBIG2, LZW, or FlateDecode streams | Refused — whole job stops |
| DecodeParms dictionary present | Refused — whole job stops |
| Inline images (drawn inside the content stream) | Not claimed as removable by this version |
The first two rows cover most straightforward embedded photographs and grayscale scans. The rest of the rows are exactly the cases that, in older in-place editors, silently produce broken PDFs when the page content stream references an image object that no longer exists. By swapping the stream in place rather than deleting the object, the rewrite keeps every resource reference valid.
What Stays Untouched After the Swap
The rewrite is targeted, which is why the rest of the document survives intact. Once the swap passes the safety checks, you can expect the following to be preserved exactly as they appeared in the source:
- Page count and page order. Nothing in the page tree is touched, only the image XObject payloads that page content commands reference.
- Page geometry, including crop boxes and rotation. Page media boxes and rotation dictionaries are unrelated to image streams.
- Selectable text. The tool does not rasterize any layer, so the text objects and fonts on each page keep their original instructions and remain searchable and copyable where the source supports it.
- Internal and external link annotations. Annotations live in their own dictionaries and are not part of the image-object swap.
- Non-image vector content. Vector drawings and line art ride through the operation unchanged.
What does change is the appearance of any page region that previously rendered one of the stripped image objects. That region now renders the 1×1 white JPEG positioned where the original command expected it, which is visually a white patch but structurally a different operation from layered painting.
When This Workflow Is and Isn't the Right Choice
The approach fits work where a white replacement is acceptable and the priority is preserving everything else around the image. Typical fits include shareable drafts where a stray photograph should not travel with the file, scan-heavy documents that need the look of a clean page without the original paper artifacts, and reference PDFs where the text, links, and page geometry matter more than the embedded graphics.
Three cases call for a different tool. The first is true legal, security, or privacy redaction — a white-rectangle swap is not a certified legal removal, retained metadata or inaccessible original history may still matter, and a dedicated redaction workflow is the right starting point. The second is single-image surgery: if you want to delete one specific image and keep everything else around it, an editor that lets you select objects (Nitro's Edit and Crop Images mode, Acrobat's content-editing mode, or pixel-level redaction tools) will leave you with more control. The third is password-protected, encrypted, or signed PDFs: the tool does not bypass password protection on these documents, and an unprotected copy may need to be produced separately.
Keep the source document. Open every output page. Treat the white-patch outcome as a visual transformation, not as proof that the underlying graphics have been erased from a forensic standpoint. For those use cases, the answer is still "use a real redaction pipeline" — but for the everyday job of stripping the photos and scans that bloat a PDF before you forward it, the browser-based swap is enough.