How do I automate splitting PDFs every week?

Put incoming PDFs in an inbox folder, write a short script that splits each file by a clear rule and moves the original to an archive, then run that script from your operating system's built-in scheduler once a week. Add logging and a page-count check so failures are noticed rather than silent.

What does a weekly PDF splitting workflow look like?

A weekly split job has four parts: a folder that receives files, a script that processes them, a scheduler that runs the script, and an output folder with a record of what happened.

Keep the stages separate:

Inbox: where new PDFs land, by hand or from a scanner or export.
Processing: the script splits each file and writes the results elsewhere.
Archive: originals move here once they succeed.
Failed: anything that errors goes here for you to inspect.

This layout makes the job safe to rerun. If the machine was off on the scheduled day, the next run simply picks up whatever is waiting in the inbox.

Decide your splitting rule before writing anything. Common rules are one page per file, fixed chunks of N pages, splitting at blank separator pages, or splitting by bookmarks. Fixed rules are simplest and most predictable. Content-based rules, such as detecting a barcode or a heading, need more work and more testing.

Write the rule down in plain language first, for example: 'Split each statement into one file per account, named by account number and date.' That sentence becomes your specification and your test. If you cannot state the rule that clearly, automate it later.

Which tools can split PDFs from the command line?

Most technical users choose between a command-line PDF utility and a scripting library. Both run offline, which matters if the documents are sensitive.

Command-line utilities are quick to wire up. They typically let you extract page ranges, burst a document into single pages, or join files together with one line each. They suit fixed rules such as 'every page separately' or 'pages 1-4 and 5 to the end'.

Scripting libraries give you control. You can open a file, read its page count, inspect the text on each page, decide where to cut, and write named outputs. This is the better route when the split depends on content.

Whichever you pick, check these points before committing:

Does it preserve bookmarks, form fields and metadata, or drop them?
Does it cope with encrypted or password-protected files?
Can it handle large files without loading everything into memory?
Does it return a non-zero exit code on failure, so your scheduler can notice?

Test on a handful of real files, including awkward ones: a scan, a file with mixed page sizes, and one that is slightly corrupt. Tools often behave identically on tidy samples and very differently on messy ones.

How do I schedule the job to run every week?

Every mainstream operating system has a built-in scheduler, and that is usually all you need. You give it a day, a time and a command, and it runs your script unattended.

For a weekly job, set:

Day and time: pick a quiet slot, such as early morning, when nobody is editing files in the inbox.
Full paths: use absolute paths to the script, the interpreter and the folders. Schedulers run with a minimal environment, so relative paths and shortcuts often fail.
Working directory: set it explicitly inside the script.
Logging: redirect output and errors to a dated log file.

If the computer might be asleep or off at the scheduled time, look for a 'run missed jobs' or catch-up option, or schedule the task on an always-on machine or small server instead.

Add a lock so two runs cannot overlap. A simple approach is to create a lock file at the start and delete it at the end; if it already exists, the script exits. This stops a slow run from colliding with the next one.

Finally, test the scheduled task by setting it to run in two minutes. Many failures only appear under the scheduler, not in your own terminal.

How do I handle scanned PDFs and name the output files?

Scanned PDFs contain images rather than text, so any rule based on content needs OCR first. Run OCR before splitting if you want to split on text, or after splitting if you only need searchable output files.

A sensible order for content-based jobs:

Run OCR on the whole file and save a searchable copy.
Read the text from each page.
Find split points, such as a heading, a reference number or a blank page.
Write each section as its own file.

For OCR, use a local engine and set the language explicitly; accuracy drops when it has to guess. Scan resolution matters too, and around 300 dpi is a common starting point for ordinary print. Skip pages that already contain text to save time.

Naming deserves as much thought as splitting. Build names from stable data:

the original filename without its extension
a page range or sequence number with leading zeros
a date or extracted reference

For example, invoice-batch_0001-0003.pdf sorts correctly, while invoice-batch_1-3.pdf does not once you pass nine files. Strip characters that cause trouble in filenames, and never overwrite an existing output; add a suffix instead. Keep the original untouched until the whole run has succeeded.

How do I make the weekly job reliable and safe?

An unattended job needs to fail loudly and never destroy data. Build these habits in from the start.

Never modify originals in place. Write outputs to a separate folder and move the source into an archive only after every output file is written and verified.

Verify the result. For a plain page split, the page counts of the outputs should add up to the page count of the input. If they do not, move the file to the failed folder and log why.

Handle errors per file. One bad PDF should not stop the other forty. Wrap each file in its own error handling and carry on.

Log enough to debug later. Record the start time, each filename, the rule applied, the number of outputs and any error. Keep a few weeks of logs, then rotate them.

Get notified. A short summary written to a file you check, or an email sent from your own mail setup, is enough. The most dangerous failure is silence.

Back up. Local automation means your archive is only as safe as your disk. Copy it somewhere else on a schedule.

Because everything runs on your own machine, sensitive documents never need to be uploaded anywhere. Review the first few weeks of output by hand, then spot-check occasionally.

Frequently asked questions

Can I split PDFs automatically without uploading them anywhere?

Yes. Command-line tools and scripting libraries run entirely on your own computer, so the files stay local. Check that any tool you choose does not call out to an online service.

What if the computer is off when the weekly job is due?

Enable a catch-up or 'run missed jobs' option if your scheduler has one, or run the task on an always-on machine. Since the inbox holds unprocessed files, the next run will still pick them up.

How do I split a PDF at blank pages?

Read each page's text or image content, treat pages with almost no content as separators, and cut at those points. Test on real scans first, because specks and scanner noise can make blank pages look non-blank.

Related on B.A.I.S.

The PDF Toolkit script gives you the same OCR, split and merge automation we use for client work, as a script you run locally on your own schedule. Your files never leave your computer.

Need this done for you? PDF Toolkit script (run it yourself)