Six monthly bank statements and two invoices arrived as eight separate PDFs, 56 pages in total, and the lender wanted one attachment. The phone was an Android device with no PDF editor installed. The whole job ran in Chrome: select the files from Downloads, put them in order, merge, then open the downloaded result. This guide covers the browser route, the rules that decide whether a file is accepted, and the memory habits that keep a long merge from dying halfway through.
Part of the PDF workflow guide. Merge in the PDF merge tool; build a PDF from photos first with image to PDF. For cover pages and chapter order, see merge order.
Why a browser is enough on Android
The merge engine runs as JavaScript on the page. When you choose PDFs, the browser hands their bytes to that page, which parses each document and writes a new one in memory. The original files stay on the phone. No upload, no account and no Play Store install are involved. Chrome, Firefox and Samsung Internet can all run the page, though the file picker and download interface differ slightly between them.
The fixed limits are 2 to 20 PDFs, 10MB per file and 200 pages total. Encrypted documents and corrupt downloads fail, because the engine cannot read them. Processing is local, so there is no server queue and no cloud retry. Android may also stop or reload a background browser tab when memory is low, which is why a large merge deserves a little preparation.
The system file picker is the only access route. It lets you pick PDFs from locations such as Downloads or Files, but the page does not become a file manager, a cloud-sync client or a storage integration. It sees the copies you select, and nothing else. If a PDF is not visible in the picker, move it to Downloads or use the picker's own browse option before blaming the merge tool.
Prepare the PDFs and the order
Gather the documents in Downloads or Files and rename them with a numeric prefix: 01-cover.pdf, 02-statement.pdf, and so on. The browser list shows names and sizes, so clear names make a wrong sequence easy to spot. Check each file against the 10MB cap, count the files, and add up the pages. A 20-file set that totals 240 pages will be rejected even though every individual file is small.
Unlock password-protected PDFs before adding them. Bank statements and payslips often carry owner restrictions that block parsing. If you do not have the password, request an unlocked copy from the issuer rather than experimenting with the file. A corrupt download also fails; download it again rather than adding the same broken file repeatedly.
Decide the final sequence before the first tap. New files are appended to the end of the list, and there is no drag handle. If a file belongs earlier, remove it and add it again at the correct point. For images that need to sit between existing pages, build a separate image PDF and split the original PDF around the insertion point first; the merger cannot interleave pages from two documents.
Merge PDFs in Chrome or another Android browser
- Open the browser and navigate to the PDF merge page.
- Tap Add PDFs. In the system picker, choose Downloads or Files and select a PDF. Multi-select works in many pickers; if it does not, add files one at a time.
- Check the numbered list after every addition. Each row shows the file name and size, and the row number is the page position.
- Fix the order by removing a file and adding it again at the end. Repeat until the list matches your plan.
- Confirm 2 to 20 files, each 10MB or less, with an expected total of 200 pages or fewer.
- Tap Merge. Leave the page in the foreground and wait for the success message with the file and page counts.
- The browser downloads
merged.pdf. Open the download notification or find it in Downloads, rename it, then share or move it with your file manager.
Android browsers usually surface a completed download in a notification and in the Downloads folder. The exact wording and location depend on the browser, so verify the file before closing the tab. If the success message appears but the file is not where you expected, check the browser's own downloads screen rather than assuming the merge failed.
Memory, long documents and the hard limits
Chrome on Android is aggressive about reclaiming memory. A tab that is switched away from can be discarded, and returning to it may reload the page with an empty file list. A 200-page PDF can be memory-heavy even when it is only 8MB on disk, because the parser has to hold page structures and copied content. Keep the merge page visible, close unused tabs, and download the result before starting anything else.
For a long set, merge in parts. Finish one batch, download it, then start the next. If you later need to join the parts, each part must be under 10MB and the combined page count must stay within 200. That second pass is still a normal merge of 2 to 20 PDFs; there is no special append mode. Keep the part files until the final document opens correctly.
| Scenario | Recommended action | Reason |
|---|---|---|
| 2 to 5 short PDFs | Merge in one run | Fast and light on phone memory |
| One file close to 10MB | Add it with small files and wait | The per-file check rejects anything over the cap |
| 20 files | Use numeric names and verify the list | 20 is the ceiling and order is add order |
| Over 200 pages | Split or shorten the sources first | The merger stops at 200 total pages |
| Locked or damaged PDF | Unlock it or download a fresh copy | Encrypted and corrupt files cannot be parsed |
| File in the wrong place | Remove it, then add it again | There is no drag reorder in the list |
| Tab discarded by Android | Retry with smaller batches | Background tabs lose their in-memory state |
Two worked examples
Example 1: six statements and two invoices. The set had six nine-page statements between 1.1MB and 2.9MB, and two one-page invoices at 240KB and 310KB. That is 8 files and 56 pages, comfortably inside every limit. I added them in statement order, with the invoices last, checked the numbered list, and merged. The success message reported 8 files and 56 pages. The download was about 9.1MB, so the page count and file size were both checked before emailing it to the lender. A missing statement would have shown up as 47 pages instead of 56.
Example 2: a 21-file archive. A client sent 21 small PDFs covering 192 pages. The page total was fine, but the file count was one over the maximum. I merged the first 20 into part-1.pdf, downloaded it, then merged that result with the last file to produce the final 21-source bundle. The intermediate file was 9.4MB, under the per-file cap, and the second pass stayed within 200 pages. The alternative was to ask for one file to be combined at the source, which is cleaner when the sender can do it.
File size and page count are separate limits. A set can be under 10MB per file and still fail because it has 201 pages, or be under 200 pages and fail because one scan is 11MB.
Verify before you send
Open the downloaded PDF in any Android PDF viewer and compare the page count with your expectation. Inspect the first page, a middle page and the final page. Use the printed page numbers to confirm the sequence, then check rotation, legibility and blank pages. If the file will be printed, zoom in on small type rather than judging from the thumbnail.
Confirm the size against the recipient's upload limit and rename the file by content and month, such as loan-docs-2026-10.pdf. Keep the source PDFs until the recipient confirms receipt. Merging can flatten form fields, signatures and annotations into static page content, so retain editable originals if you may need to change them. If the order is wrong, rebuild from the sources; editing the merged file is more work and risks losing pages.