Use the viewer's page counter, not the printed folio.
Each chapter ends on the page before the next one begins.
Plain sorting puts 10 before 2 otherwise.
The printed page number and the PDF page index are rarely the same: covers, blank leaves, roman numerals and inserted plates all shift the count. Use the viewer's page indicator (the 3 / 128 field), never the folio printed at the bottom. Write down every chapter start as you go; five minutes here saves redoing the whole split.
A chapter ends on the page before the next one starts, so only the last range needs the document's final page. Write them as 1-12,13-28,29-45 and check that the total adds up. If it does not, you have a gap or an overlap — and an overlap is worse, because it silently duplicates pages instead of failing loudly.
Splitters usually name results after the source plus a range suffix, and plain string sorting puts 10-19 before 2-9. If order matters downstream (uploading, printing, sending in sequence), prefix 01-, 02- once the files are out. Renaming twenty files is tedious, but it is the difference between a usable set and one that gets reassembled wrong.
Chapter splitting wants ranges. One-file-per-page produces a zip of 128 files and then you have to merge them back: two steps and twice the chance of an ordering mistake. Keep that mode for cases where each page really does go to a different recipient.
Open the first and last page of each output and check that the running title matches the chapter name. A split that is off by one page looks perfectly fine in a file list and is only discovered by whoever reads it.
If the PDF has a proper outline, some tools can; otherwise read the outline's page targets and use ranges.
The range started past the final page — check the real page count.
No. Pages are reassembled, not re-rendered, so text and images stay intact.