Why I built this
In March 2026 I needed to combine 47 receipt PDFs from credit card statements into one document for my Korean income tax filing (종합소득세 신고). Every year the tax office wants supporting documents bundled, and every year I waste an hour fighting with online PDF tools. The first three sites I tried wanted me to upload everything to their servers — including financial information I would rather not hand to a stranger. The second site required a $9.99/month subscription after three free uses. The third inserted a faint "Made with FreePDF.com" watermark across the bottom of every page, which would look terrible on a tax submission.
What annoyed me most was opening DevTools out of curiosity on one of those sites and watching my 12 MB statement PDF upload — page by page — to a server I had never heard of. There was no privacy notice, no encryption indicator, nothing. My financial data was just sitting in someone's S3 bucket so they could call pdf-lib.mergePdfson it and charge me money for the privilege.
So I built this. Three rules: (1) nothing uploads, ever; (2) no signup, no email, no credit card; (3) no watermark, no metadata injection, no upsell modal. The merge happens entirely in your browser using pdf-lib — the same open-source library that several "premium" competitors quietly use on their server side. Your files never travel to a server, and there is no upload progress bar because there is nothing to upload.
How it works under the hood
When you drop PDFs onto the page, each file is read into a JavaScript ArrayBuffer using the FileReader API — a browser primitive that operates entirely in memory. The bytes never touch any network. pdf-lib then parses each ArrayBuffer into a PDFDocument object: it walks the cross-reference table, decompresses object streams, and builds an in-memory graph of pages, fonts, and shared resources.
The merge itself is a series of copyPages() calls. Importantly, pdf-lib copies page objects by reference rather than re-encoding them — the page's content stream (drawing instructions), embedded fonts, and image XObjects are pulled into the destination document as-is. This is why the merge is fast (a few hundred milliseconds even for hundreds of pages) and why visual fidelity is byte-perfect.
The bottleneck is RAM. Each parsed PDF roughly doubles in memory size relative to its on-disk size (decompressed streams plus the JS object graph). A merge of fifty 50 MB PDFs would need ~5 GB of headroom, which exceeds most browser tab limits (~2 GB on desktop Chrome, ~1 GB on mobile Safari). For typical document workflows — 5 to 50 files of a few MB each — this is invisible.
Verify yourself: open DevTools → Network tab, clear the log, drop your PDFs, click Merge. You will see exactly zero outgoing requests carrying your PDF content. The only network traffic is the initial page load (HTML, JS, CSS) which is cached after first visit.
Real use cases
- Tax filing season (Korea or US): Combining 30-50 receipt PDFs into one submission for 종합소득세 or a Schedule C audit. Privacy matters here because receipts reveal where you eat, shop, and travel.
- Job application bundles: Resume + cover letter + portfolio + reference letters into one PDF for ATS systems that accept only a single upload. No watermark means no awkward conversation in the interview.
- Real estate closings: Mortgage docs, inspection reports, title work, and HOA disclosures into one binder for record-keeping. These contain SSNs and bank info — exactly the wrong thing to upload to a free hosted tool.
- Academic submissions: A thesis chapter plus appendices plus signed committee form into one final PDF for the university registrar. Most departments want a single file, not three.
- Family records (가족 단톡방 use case): Combining scanned 가족관계증명서, 주민등록등본, and 인감증명서 for a banking or visa application. Korean civil documents are inherently sensitive and uploading them anywhere outside a government portal is a poor practice.
vs other PDF tools
How OhMyPDF Merge compares to the four most-Googled competitors as of May 2026:
| Feature | OhMyPDF | iLovePDF | SmallPDF | Adobe Online |
|---|---|---|---|---|
| Free tier | Yes | Limited (2/day) | Limited (2/day) | 7-day trial |
| No upload to server | Yes | No | No | No |
| No signup required | Yes | Limited use | Limited use | Adobe ID |
| No watermark | Yes | Yes | Yes | Yes |
| Unlimited merges | Yes | Paid only | Paid only | Paid only |
| Source code inspectable | Yes (browser) | No | No | No |
| Max input size | 100 MB/file | ~5 GB | ~5 GB | Very large |
Where the competitors win: iLovePDF and Adobe can merge 1 GB+ scanned documents because they have GBs of server RAM. We are bounded by browser memory. For one-off enormous merges (a scanned medical record archive, for instance), they remain a legit choice. For everyday document work — receipts, contracts, applications — staying local is the better default.
What this can't do
- Preserve bookmarks (outlines). pdf-lib does not yet copy the outline tree between documents. Page content is fine; the sidebar navigation in long documents is lost.
- Decrypt user-passworded PDFs. We honor encryption — files locked with a real password must be unlocked elsewhere first. This is a deliberate choice, not a technical gap.
- Merge files over 100 MB each. Browser memory is a hard ceiling — even Chrome on a 64 GB workstation isolates each tab to roughly 2 GB. Large scanned-image PDFs hit this fast.
- Re-render to a uniform page size. A merge of A4 + Letter keeps both sizes; we do not rasterize and re-fit.
- Add page numbers or a table of contents. That requires a re-encode pass we do not run in-browser.
If you need any of these, use Adobe Acrobat Pro (desktop) or PDFtk Server — both are mature tools designed for power workflows.
Tips for best results
Name your files numerically before importing. Files like 01-cover.pdf, 02-resume.pdf, 03-portfolio.pdf sort cleanly in the file picker so the list appears in your intended order — saves the reorder step. Two-digit prefixes matter; 1.pdf through 10.pdf sorts as 1, 10, 2, 3...
Compress before merging if you are tight on memory. If you know you will hit a memory wall, run heavy-image PDFs through the Compress tool first. A 60 MB scanned PDF often shrinks to 8 MB without visible quality loss, which makes the merge comfortably fit.
Verify the merge by opening it. PDF viewers can render a file even if the structure is slightly broken. After merging, open the output and scroll all the way through — first page, last page, every section divider. Takes 30 seconds and catches the rare cases where a page failed to copy.
Keep originals until you have confirmed the merge. Do not delete source PDFs until you have opened the merged output end-to-end. This is muscle memory worth building.
FAQ
Will the order of pages match the order of files I added? Yes — files are concatenated in the visible list order, and within each file the pages stay in their original order. Use the up/down buttons or drag to rearrange before merging. If you renamed a file in your OS file picker, the new name shows up here, but the merge tool uses the order in our list, not the alphabetical or modified-date order from your file system. Double-check the list one last time before clicking Merge — the most common mistake is forgetting to reorder a receipt or cover page.
Are bookmarks preserved? No. pdf-lib (the underlying browser library) does not yet copy outline entries (the sidebar bookmarks tree) between documents. Page content, embedded fonts, vector graphics, raster images, annotations, and form fields are preserved. If bookmarks are critical to your workflow — for example a 300-page report with chapter navigation — use Adobe Acrobat Pro or PDFtk on the desktop, which still own that capability. For 95% of typical merge tasks (receipts, contracts, invoices), the loss of bookmarks is a non-issue.
Does the merge re-encode page contents? No. Pages are copied by reference into the new PDF, so visual quality is byte-for-byte identical to the source files. Output file size is roughly the sum of input sizes, sometimes slightly smaller because shared resources (like the same font embedded in two PDFs) get deduplicated automatically. This is why a merge of ten 5 MB PDFs usually lands around 48-50 MB, not 50 MB plus overhead.
Is there a maximum number of pages? There is no hard page limit, but each input PDF is capped at 100 MB and you can merge up to 50 files at once. The real limit is your browser memory — desktop browsers handle multi-thousand-page merges without issue, but Safari on iPhone caps each tab around 1 GB of RAM, so very large merges can crash there. If you hit a crash on mobile, do the merge in two passes (combine batches of 10, then combine the batches) or use a desktop browser.
Do you upload my PDFs to a server? No. All processing happens inside your browser tab using the pdf-lib JavaScript library. You can verify by opening DevTools (F12 or right-click → Inspect), clicking the Network tab, clearing the log, then clicking Merge. You will see zero outgoing fetch or XHR requests carrying your PDF bytes — only the static assets that loaded with the page itself. Most hosted competitors cannot make this claim because their business model requires the file to reach their server.
Can I merge password-protected PDFs? PDFs with empty owner passwords (just permissions restrictions like "no copying") load fine — pdf-lib silently ignores those flags. Files with a real user password (the kind that prompts for entry before opening) must be unlocked first in a desktop tool because we do not break encryption on principle. If you legitimately own the file, use our PDF Unlock tool or Adobe Acrobat to remove the password, then come back to merge.
Why is the merged PDF size sometimes larger than the sum of inputs? Two reasons: pdf-lib rewrites the cross-reference table and object dictionary, which can add a few KB of overhead per source file. Second, some source PDFs use deeply compressed object streams that pdf-lib expands into a more standard layout. The difference is usually under 5%. If size matters, run the merged output through the PDF Compress tool afterwards — that often recovers the overhead.
Can I merge PDFs with different page sizes (A4 + US Letter)? Yes. Each page keeps its original dimensions in the merged document, so a 50-page output can have a mix of A4, US Letter, and even unusual sizes like A3 or photo prints. PDF readers handle this fine — each page just displays at its native size. If you need uniform sizing for printing (e.g., everything resized to A4), that requires a re-render step which we do not do here; use a desktop tool like Adobe Acrobat.
Why would I use this instead of iLovePDF or SmallPDF? Three reasons: privacy (your files never leave your browser, theirs do), no caps (they limit free tier to 2-3 merges per day, we have no limits), and no signup (they push accounts hard, we have none). The trade-off is they can handle 1 GB+ files because they run on servers with abundant RAM, while we are bounded by browser memory. For sensitive documents — tax filings, contracts, medical records — we are the safer pick.
My output looks wrong — pages out of order or missing. What happened? Most often this is the reorder step being skipped. The merge follows the visible list, not file names. If a file appeared "missing," check the file size column — a 0 KB or grayed-out row means the file failed to parse (usually because it is corrupted or password-protected). Remove the problem file and retry. If pages within a single source PDF are out of order, the source itself has them out of order — open the source in any reader to confirm.