How do I Bates number PDFs on a Mac?

What differs between Safari and Chrome here

One thing, and it is about where the output goes. Chrome and Edge support writing directly into a folder you pick, so stamped files appear next to each other as they finish. Safari and Firefox do not implement that, so the run collects the output and hands you a single ZIP at the end. The stamping itself, the sequencing, the verification pass, the manifest and the load files are identical.

Everything else is ordinary macOS behaviour: drag from Finder, drop on the page. Files can also come from an external drive or a mounted share — they are read through the browser’s file APIs, not copied anywhere first.

Apple Silicon, and why performance is not the interesting question

The work is JavaScript and WebAssembly in the tab, so it runs natively on Apple Silicon with no translation layer, and a set of a few hundred ordinary documents finishes in the time it takes to read the confirmation. The real constraint is memory rather than CPU: each PDF is held while it is written, so a set of very large scans is where a Mac with 8 GB will complain first. If OCR is switched on for a scanned set, that is the slow step by a wide margin.

What you get, which is the same on every platform

One continuous sequence across the set with a prefix, suffix and digit padding you choose; reserved thousands at document boundaries; a refusal to reissue ranges you declare as already produced. The number placed against each page’s own crop box and rotation, as a real text object that Ctrl+F and a review platform can find. Every output re-opened and checked before delivery. A manifest CSV with page count, BegBates, EndBates and a SHA-256 per document, plus optional Summation .dat and Opticon .opt load files. And the metadata and redaction checks over the same queue, which are the two things that leak out of a production that was numbered perfectly.