A browser tool is enough for a one-off batch and runs until memory becomes the limit, usually at hundreds of pages rather than thousands. A job that recurs is worth scripting.
Batches break in three places: filename ordering, memory, and nobody verifying the output. Plan for all three before starting.
The work is usually dull and repetitive: compress a folder of scans, add a watermark to thirty reports, split a hundred invoices into individual files. Doing it one at a time is unbearable and doing it in bulk introduces risks that doing it one at a time does not have.
Choosing an approach
For most real batches
- Nothing installed, nothing uploaded
- Immediate visual feedback on what is happening
- Limited by the memory of the machine
- Manual, so no scheduling or repetition
For large or recurring work
- Repeatable and schedulable
- Processes files one at a time, so memory is not a limit
- Requires setting up and some technical comfort
- Errors are silent unless you check for them
The dividing line is whether the job will recur. A one-off batch of eighty scans is a browser job. The same operation every Monday is worth scripting, because the setup cost is paid once and the ordering and verification steps can be built in.
Filename ordering
Ordering is the most predictable way a batch goes wrong. Text sorts one character at a time, so file10 comes before file2. Any batch that runs past nine unpadded files will process or combine them in an order nobody intended. Why a merged PDF comes out in the wrong order walks through the same fault after the merge has already happened.
File managers hide this by using natural sorting, which reads runs of digits as numbers. Shell wildcards such as *.pdf and many upload forms do not, so a folder that looks correctly ordered can be handled differently by the tool acting on it. PDFslime's Merge PDF tool does sort numerically when you press Sort by name, and it lists the order before it builds anything, so you can check it there.
Memory limits
Browser-based processing holds the document in memory while it works. That is what keeps files off other people's servers, and it means capacity is bounded by the machine rather than by a policy.
For most batches this never matters. It starts to matter with very large scanned documents, where each page is a high resolution image, and with operations that need the whole document in memory at once, such as merging. A tab that becomes unresponsive or a process that fails partway through is usually this rather than a bug.
- Split large batchesWork in smaller groups
- Merge in stagesCombine halves, then the halves
- Compress before mergingOnly for very large scans
- Close other tabsThey compete for the same memory
- Prefer desktop over phoneConsiderably more headroom
Verification is the step people skip
The defining property of batch work is that a mistake applies to everything. A wrong setting on one file is a small annoyance. The same setting across ninety files is an afternoon of rework, discovered by someone else.
Run one file first
Pick a representative one, ideally the most complex in the set, and process it alone. Check the output properly before starting the batch. A wrong setting shows up on that one file instead of on all of them.
Check the counts afterwards
Files in against files out. Pages in against pages out where the operation preserves page count. A discrepancy is the fastest signal that something failed partway.
Spot-check the extremes
The first output, the last, and the largest input. Failures cluster at the beginning, the end, and on whichever file stressed the process hardest.
Output naming
A batch produces many files and their names are the only thing distinguishing them later. Suffixes describing what was done, such as -compressed or -signed, make the state of each file obvious months afterwards.
Avoid overwriting inputs with outputs even when the tool offers it. Beyond losing the originals, it makes a partially completed batch impossible to resume, because you can no longer tell which files were processed and which were not.
Every PDFslime tool in one place
Merge, split, compress, protect and more, all running in your browser with nothing uploaded.
Common questions
Scaling up without losing control.
01How many files can I batch in a browser?
There is no file-count limit, only the memory of the browser tab, so count pages and image weight rather than files. Fifty short text PDFs can be lighter than one long scanned report. If a batch stalls, split it into smaller groups.
02Why did my batch process files in the wrong order?
Filename sorting. Text is compared character by character, so file10 sorts before file2. PDFslime's Merge PDF has a Sort by name button that compares the numbers as numbers, so it puts file2 first, but the next tool in your chain may not. Padding the numbers to the same length fixes it everywhere.
03Should I compress before or after merging?
After, in almost every case. Before compressing the merged file at all, check its size: if the parts were already compressed, it may already be small enough, and a second pass only re-encodes the same images again.
04How do I check a batch worked?
Process one representative file first and inspect it properly. Then compare input and output counts, and spot-check the first, last and largest results. Failures cluster at the beginning, the end and on the heaviest file.
05When is scripting worth the setup?
When the job recurs, or when the batch is too large for a browser tab. A script handles one file at a time, so memory stops being the limit, but it needs its own checks. Have it log each file's page count in and out, so a file that failed quietly shows up in the log.
06Should I let the batch overwrite the original files?
No. Work on a copy and write outputs to new names. Batch operations apply a mistake to everything at once, and keeping the originals turns a bad run into a retry rather than a loss.