In earlier how-to guides for page extraction<\/a>, the advice was often very literal: \u201cPick pages 1\u20133, extract them, download a new PDF.\u201d That still works, but real-world document workflows<\/a> have become more demanding. Teams now expect extraction to power automated routing, generate visual previews, and run safely at scale without tying up a web request.<\/p>\n\n\n\n What\u2019s changed \u201cfrom before to today\u201d is less about the basic goal\u2014pull certain pages out of a PDF\u2014and more about how<\/strong> you design the extraction step. Modern usage leans on three upgrades:<\/p>\n\n\n\n This article focuses on those practical shifts and shows how to build a page-extraction workflow that feels current, robust, and production-friendly.<\/p>\n\n\n\n Page ranges are the difference between \u201cit works for one document\u201d and \u201cit works for every document.\u201d In real operations, \u201cextract pages<\/a>\u201d usually means one of three things:<\/p>\n\n\n\n Modern page range strings let you represent these business intents cleanly, without building custom logic for each scenario. If your system is customer-facing\u2014where users type their own ranges\u2014page range rules also become a user-experience feature: the simpler the syntax, the fewer support tickets you get.<\/p>\n\n\n\n A lot of older implementations treated extraction as a hard-coded action:<\/p>\n\n\n\n That approach breaks down as soon as page counts vary, documents merge, or a form adds a new section.<\/p>\n\n\n\n A current approach treats page ranges as a small language<\/strong> you generate (or accept from users), validate, and pass to the API. You build reusable patterns like:<\/p>\n\n\n\n This upgrade sounds small, but it\u2019s the foundation for scalable extraction.<\/p>\n\n\n\n The page range syntax supports common patterns in a condensed, readable way. Below are the practical \u201crecipes\u201d you\u2019ll reuse across projects.<\/p>\n\n\n\n Use commas to list exact pages:<\/p>\n\n\n\n This is ideal when you know the exact pages you need (signature page, disclosure page, a specific exhibit), or when a workflow selects pages based on a rule you already computed.<\/p>\n\n\n\n Use hyphens for ranges and commas to combine them:<\/p>\n\n\n\n This is the most common pattern in operational work: \u201cgrab the first section, skip the middle, then grab a later section.\u201d<\/p>\n\n\n\n Use a leading hyphen to represent \u201cfrom the beginning through page N\u201d:<\/p>\n\n\n\n This is extremely useful when the \u201cfront matter\u201d is consistent while the rest of the document varies.<\/p>\n\n\n\n Use a trailing hyphen to represent \u201cfrom page N through the final page\u201d:<\/p>\n\n\n\n This supports the classic \u201cappendix starts here\u201d or \u201ceverything after the summary\u201d workflow without needing to know the final page count up front.<\/p>\n\n\n\n Some API samples show page-range strings that include The safest way to handle this in a real product is:<\/p>\n\n\n\n This small test prevents the most painful class of bugs: \u201cIt extracted the wrong page and nobody noticed until a customer complained.\u201d<\/p>\n\n\n\n A major evolution in page extraction is that you\u2019re no longer limited to producing only PDFs. The output format you choose determines what you can do next in your workflow.<\/p>\n\n\n\n Choose PDF output is best for downstream steps that still operate in \u201cdocument mode.\u201d<\/p>\n\n\n\n Choose PNG is often preferred for crisp UI previews (especially for text-heavy pages), while JPEG can be smaller and faster to load for image-heavy pages. The right choice depends on your product goals: sharpness vs bandwidth.<\/p>\n\n\n\n If your workflow is \u201cshow the reviewer pages 1, 5, and 10 as thumbnails,\u201d you\u2019d set the format to Here\u2019s a cleaned-up cURL template (fixing the common quoting\/header issues that trip people up):<\/p>\n\n\n\n Even when you\u2019re producing images, many teams keep When your output format is PDF, Use This is the \u201cmake it easy for humans\u201d choice: one file, one download, one share.<\/p>\n\n\n\n Use This is the \u201cmake it easy for systems\u201d choice: separate objects that can be tagged, routed, or retried independently.<\/p>\n\n\n\n In older implementations, teams often extracted pages and then wrote extra code to split the result again, or they performed separate extraction calls for each page. Today, you design the job once using One of the most meaningful shifts in \u201cmodern\u201d usage is operational: the extraction request is job-based<\/strong>. Instead of returning the final file immediately, the API typically returns a status reference first, then later provides a download URL when the job finishes.<\/p>\n\n\n\n If you try to keep a request open until extraction completes, you invite failures:<\/p>\n\n\n\n Async job handling avoids those problems and fits neatly into queues and background workers.<\/p>\n\n\n\n A practical workflow usually looks like this:<\/p>\n\n\n\n This model scales cleanly: you can process many documents without tying up web threads or blocking user sessions.<\/p>\n\n\n\n Before, developers often wrote \u201csingle-shot\u201d flows: call extraction, wait, download. Today, reliable implementations assume a job lifecycle from the start and design around it.<\/p>\n\n\n\n That changes where you put logic:<\/p>\n\n\n\n In other words, extraction becomes a true workflow step instead of a one-off utility call.<\/p>\n\n\n\n If you want your implementation to stay stable as templates evolve, treat page-range strings as generated outputs of reusable recipes. This is where you gain long-term flexibility.<\/p>\n\n\n\n Most teams can cover their needs with a handful of templates:<\/p>\n\n\n\n Then you map each document type to a recipe rather than a rigid list of page numbers.<\/p>\n\n\n\n Whether your range is generated or user-entered, validation prevents silent failures and wrong-page extraction. Basic checks include:<\/p>\n\n\n\n Normalization is also helpful: remove spaces, standardize commas, and ensure the string is clean before calling the API.<\/p>\n\n\n\n If your UI is 1-based (recommended for user clarity), keep it 1-based everywhere in your product logic and only convert at the boundary if the API requires it. Don\u2019t mix conventions inside your system.<\/p>\n\n\n\n This is one of those \u201cyou only learn it the hard way\u201d lessons: indexing ambiguity causes the most damaging extraction bugs.<\/p>\n\n\n\n Extraction is easy to demo and surprisingly easy to break at scale. These practices make the difference between a script and a service.<\/p>\n\n\n\n Polling too aggressively can waste resources and increase the chance of transient failures. A simple pattern is:<\/p>\n\n\n\n Store:<\/p>\n\n\n\n If a worker restarts, you don\u2019t want to lose track of jobs in progress.<\/p>\n\n\n\n Name outputs with meaningful identifiers (document ID, timestamp, workflow step). This makes auditing and debugging dramatically easier, especially when customers say \u201cI got the wrong pages.\u201d<\/p>\n\n\n\n A current design chooses output format intentionally:<\/p>\n\n\n\n When format matches the workflow step, you avoid conversion steps later.<\/p>\n\n\n\n The biggest difference between \u201cbefore\u201d and \u201ctoday\u201d isn\u2019t that extraction exists\u2014it\u2019s that extraction is now sophisticated enough to serve as an automation primitive:<\/p>\n\n\n\n If you build your extraction feature around reusable range patterns, deliberate output formats, and a job-based lifecycle, you\u2019ll end up with a system that survives template changes, supports high volume, and feels fast and reliable to end users.<\/p>\n\n\n\n \u00a9 Image credits to Steve Johnson<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"\n
The Importance of Page Ranges in Real Workflows<\/h2>\n\n\n\n
\n
What \u201cbefore\u201d looked like<\/h3>\n\n\n\n
\n
What \u201ctoday\u201d looks like<\/h3>\n\n\n\n
\n
Reusable Page-Range \u201cRecipes\u201d You Can Use Everywhere<\/h2>\n\n\n\n
Choose specific pages with commas<\/h3>\n\n\n\n
\n
1,2,5<\/code><\/li>\n<\/ul>\n\n\n\nChoose multiple page ranges with hyphens and commas<\/h3>\n\n\n\n
\n
2-4,7-9<\/code><\/li>\n<\/ul>\n\n\n\nUse a leading hyphen for \u201cfrom the start to page N\u201d<\/h3>\n\n\n\n
\n
-5<\/code><\/li>\n<\/ul>\n\n\n\nUse a trailing hyphen for \u201cfrom page N to the end\u201d<\/h3>\n\n\n\n
\n
7-<\/code><\/li>\n<\/ul>\n\n\n\nWatch out for page-number indexing in examples<\/h3>\n\n\n\n
0<\/code> (for example, strings like 0,2-5,7-<\/code>). In practice, many systems treat pages as 1-based (page 1 is the first page), while some internal representations or examples may display 0-based numbering.<\/p>\n\n\n\n\n
1<\/code> vs 0<\/code>.<\/li>\n\n\n\nSelecting an Output Format: PDF vs JPEG vs PNG<\/h2>\n\n\n\n
When PDF output is the right choice<\/h3>\n\n\n\n
pdf<\/code> when:<\/p>\n\n\n\n\n
When JPEG or PNG output is the right choice<\/h3>\n\n\n\n
jpeg<\/code> or png<\/code> when:<\/p>\n\n\n\n\n
A practical example: generate PNG thumbnails for selected pages<\/h3>\n\n\n\n
png<\/code> and request those pages.<\/p>\n\n\n\ncurl --location --request POST \"https:\/\/{zohoapis_domain}\/pdfeditor\/api\/v1\/pdf\/pages\/extract\" \\\n --header \"Authorization: Zoho-oauthtoken YOUR_ACCESS_TOKEN\" \\\n --form 'files=@\"\/path\/to\/Sample.pdf\"' \\\n --form 'input_options={\"page_ranges\":\"1,5,10\",\"format\":\"png\"}' \\\n --form 'output_settings={\"name\":\"Thumbnails\",\"single_pdf\":false}'\n<\/code><\/pre>\n\n\n\nsingle_pdf<\/code> explicit in requests for clarity and consistency across code paths.<\/p>\n\n\n\nPackaging the Output: Combine or Split With
single_pdf<\/code><\/h2>\n\n\n\nsingle_pdf<\/code> becomes one of the most important controls because it changes how your extracted content behaves in storage and downstream workflows.<\/p>\n\n\n\nOne combined PDF with
single_pdf: true<\/code><\/h3>\n\n\n\nsingle_pdf: true<\/code> when:<\/p>\n\n\n\n\n
SignaturePages.pdf<\/code>).<\/li>\n\n\n\nSeparate PDFs with
single_pdf: false<\/code><\/h3>\n\n\n\nsingle_pdf: false<\/code> when:<\/p>\n\n\n\n\n
What changed from older patterns<\/h3>\n\n\n\n
single_pdf<\/code> and keep your application logic simpler.<\/p>\n\n\n\nTreat Extraction as an Async Job, Not a Synchronous Download<\/h2>\n\n\n\n
Why async matters in production<\/h3>\n\n\n\n
\n
The standard lifecycle: submit, poll, download<\/h3>\n\n\n\n
\n
What changed from \u201cbefore to today\u201d<\/h3>\n\n\n\n
\n
Building a \u201cRecipe-Driven\u201d Extraction Layer in Your App<\/h2>\n\n\n\n
Start with a small set of business recipes<\/h3>\n\n\n\n
\n
-N<\/code> (first N pages)<\/li>\n\n\n\nN-<\/code> (from N to end)<\/li>\n\n\n\nA,B,C<\/code><\/li>\n\n\n\nA-B,C-D<\/code><\/li>\n<\/ul>\n\n\n\nValidate and normalize page-range input<\/h3>\n\n\n\n
\n
9-7<\/code>)<\/li>\n\n\n\nMake indexing decisions explicit<\/h3>\n\n\n\n
Operational Best Practices for Reliability<\/h2>\n\n\n\n
Use backoff when polling job status<\/h3>\n\n\n\n
\n
Persist job state for retries<\/h3>\n\n\n\n
\n
Keep outputs traceable<\/h3>\n\n\n\n
Choose output format based on downstream needs<\/h3>\n\n\n\n
\n
pdf<\/code> for signature packets, customer deliverables, archives<\/li>\n\n\n\npng\/jpeg<\/code> for previews, reviewer UX, page thumbnails<\/li>\n<\/ul>\n\n\n\nThe Takeaway: Page Ranges Are Now a Workflow Design Tool<\/h2>\n\n\n\n
\n