Browser tools handle batches comfortably up to the point where memory becomes the limit, which is usually hundreds of pages rather than thousands.
Three things cause nearly every batch failure: 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
- Comfortable to a few hundred pages
- Limited by available memory
- Manual, so no scheduling or repetition
For large or recurring work
- Handles thousands of files without complaint
- 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 honest 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
The most common batch failure, and entirely predictable. Text sorts one character at a time, so file10 comes before file2. Any batch that runs past nine files will process or combine them in an order nobody intended.
File managers hide this by using natural sorting, which reads runs of digits as numbers. Almost nothing else does, so a folder that looks correctly ordered will be handled differently by the tool acting on it.
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 groups of twenty
- 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. This single habit catches most batch disasters.
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?
Comfortably a few hundred pages on a normal machine. The limit is available memory rather than a policy, so very large scanned documents reach it sooner than text documents. 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. Your file manager hides this with natural sorting while most tools do not. Pad the numbers so they are all the same length.
03Should I compress before or after merging?
After, in almost every case. Merging first and compressing once gives a better result, because compressing each file separately and then merging stacks two lossy passes on the same images.
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 large enough to exceed what a browser can hold. A one-off batch of eighty files is a browser job. The same operation every week justifies building something repeatable.
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.