On iPhone, you can remove a PDF password by opening the protected file in Safari, supplying the password you already know, and exporting a new unprotected raster copy of every page — with the entire process running locally in your browser tab, no app install and no server upload required. The protected PDF and its password never leave your device: the file is decoded in the browser using PDF.js, each page is rendered onto a canvas at a fixed 1.5× scale, and the rendered images are then written into a brand-new PDF without the original encryption. Because the output is rebuilt from page images rather than decrypted in place, the result behaves like a freshly scanned copy you can open, share, and print without retyping the password. This article walks through the exact iPhone workflow, the limits you need to check before you start, and what the raster copy will and will not preserve so you can decide whether the result is fit for the document you have.

Why a Browser-Based Method Fits the iPhone
The App Store restricts what most consumer apps can do to encrypted PDFs, and many third-party "PDF unlocker" apps are paid, ad-supported, or quietly upload your file. Safari, on the other hand, can run a complete client-side PDF pipeline using JavaScript libraries that ship with the page itself. Remove PDF Password is built on exactly that idea: PDF.js opens the encrypted file locally with the password you type, renders each page onto an off-screen canvas, JPEG-encodes the canvas, and pdf-lib places those images inside a fresh PDF. None of those steps needs the network, so the same tool behaves identically on an iPhone 12, an iPhone 15 Pro, or an iPad running iOS 17. There is nothing to install, no account to create, and no separate app to manage, which makes the browser tab the most predictable place to do this job on an iPhone.
Getting the Protected PDF onto Your iPhone
Before you can remove the password, you need the file in a place Safari can open. The common sources on iPhone are Mail attachments, the Files app (including iCloud Drive and On My iPhone), AirDrop from a nearby Mac, or a download from a cloud service such as Dropbox or Google Drive. Tap the PDF in Mail or Files, then use the share sheet and pick "Open in Safari," or simply drag the file from Files onto an open Safari window if you use Split View on iPad. Make sure you also have the current password written down somewhere you can read it on the phone — the tool cannot bypass or guess it, so if you no longer remember it, the workflow stops at the password prompt. You only need an internet connection long enough to load the tool page; once the page is loaded, the rest of the job runs offline in the tab.
Remove the PDF Password in Safari
- Open Safari on your iPhone and navigate to the Remove PDF Password page.
- Tap the file picker and choose the password-protected PDF from Files, iCloud Drive, or a recent download.
- Type the current password into the password field. The password is used only inside this browser tab to open the file with PDF.js.
- Tap the button that creates the unprotected copy. The tool renders every page onto a canvas at 1.5× scale and writes a new PDF with pdf-lib.
- Wait until Safari shows the preview or the download link. The completed raster copy is reopened without a password and its page count is verified before the link appears, so an incorrect password or a file that fails any limit check produces no download.
- Tap the download, then choose "Save to Files" or "Save to iCloud Drive." Open it from the Files app once to confirm pages render correctly before sharing the copy with anyone.
Limits to Check on Your iPhone Before You Start
The raster rebuild runs entirely on the device, so it has hard caps designed to keep Safari from running out of memory on a phone. If any single check fails, the job ends silently with no download, which is why it helps to estimate your file before you begin.
| Limit | Maximum value the tool accepts |
|---|---|
| Source PDF file size | 25 MB |
| Page count | 40 pages |
| Rendered page edge | 12,000 pixels on either edge |
| Rendered pixels per page | 40 megapixels |
| Rendered pixels across the whole job | 100 megapixels |
For a worked example of how those numbers interact, take a page that renders at 6,000 pixels by 4,000 pixels. Multiplying width by height gives 6,000 × 4,000 = 24,000,000 pixels, which is 24 megapixels per page — comfortably below the 40 MP per-page cap. Multiplying 24 megapixels by four pages gives 24 × 4 = 96 megapixels across the document, still under the 100 MP job cap. Add a fifth page at the same size and you reach 24 × 5 = 120 megapixels, which exceeds the job cap, so the tool would produce no download on that fifth page even though every page on its own is fine. When a document is close to one of these edges, it is usually the total pixel budget across all pages, not the per-page budget, that decides whether the iPhone job succeeds.
What the Output Keeps and What It Drops
The page size of the original is preserved, so the unprotected copy has the same dimensions as the protected file. What is not preserved is everything that lives below the visible surface of each page: selectable text, internal and external links, form fields and their values, annotation layers, digital signatures, vector objects, accessibility tags, original image encodings, metadata, and the original encryption configuration. The output is, in effect, a stack of full-page JPEGs repackaged as a PDF — visually faithful, easy to open and print, but flat. That is fine for sharing a statement with a colleague, dropping a chapter into a reading app, or printing a contract for signing on paper, but it is not a substitute for the encrypted source when the document must remain legally signed, accessible to a screen reader, or editable as a form.
iPhone-Specific Gotchas During the Run
A few iPhone behaviors are worth knowing before you tap the button. Safari on iOS can unload a background tab to reclaim memory, so once you start the raster rebuild, stay on that tab until the download link appears; switching to Mail or Messages mid-render can silently cancel the job. Larger source files take noticeably longer to render on an iPhone than on a laptop, because page decoding and canvas painting both compete with the system WebKit budget. Keep the iPhone plugged in or above about 30 percent battery if the document is near the page or pixel caps, and close other heavy tabs first. If the file is stored in iCloud Drive, give the device a moment to finish downloading the latest copy from iCloud before you pick it, because the tool reads the local file and will not see a cloud-only stub.
When a Raster Copy Is Not the Right Answer
A raster rebuild is the right call when the goal is to stop typing a password every time you open the file, and the document is being used as a visual reference. It is the wrong call when you need the file to behave like the original: a signed contract you intend to verify, a tagged PDF a screen reader must read aloud, an AcroForm a colleague has to fill in, or any document where text must remain selectable for editing or copying. In those cases, use a trusted PDF editor to perform a lossless password change on a desktop, then re-encrypt or share the result as needed. For lighter follow-up tasks on the unprotected copy — say, pulling only the pages you need into a separate file — the extract-pages browser method for iPhone picks up exactly where this one ends, still inside Safari, still with no upload.
For the technical foundations of the render-and-rebuild pipeline, the Mozilla PDF.js API documents how an encrypted PDF is opened with a user-supplied password, and the WHATWG HTML Canvas specification covers the canvas-to-blob step the tool uses to JPEG-encode each rendered page locally.