Page-Range Playbooks: Extracting PDF Pages as PDFs or Images With the Zoho PDF Editor API

Why This Update Matters

In earlier how-to guides for page extraction, the advice was often very literal: “Pick pages 1–3, extract them, download a new PDF.” That still works, but real-world document workflows 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.

What’s changed “from before to today” is less about the basic goal—pull certain pages out of a PDF—and more about how you design the extraction step. Modern usage leans on three upgrades:

• More expressive page selection using compact range “recipes” that match actual businessBusiness-to-business (B2B), also known as B-to-B, is a form of transaction between businesses, such ... More patterns.
• Multiple output formats, so extraction can produce either a PDF or page images (JPEG/PNG).
• An async, job-style lifecycle, where you submit work, poll status, then download when ready.

This article focuses on those practical shifts and shows how to build a page-extraction workflow that feels current, robust, and production-friendly.

The Importance of Page Ranges in Real Workflows

Page ranges are the difference between “it works for one document” and “it works for every document.” In real operations, “extract pages” usually means one of three things:

• Extract a limited set of pages (for example, cover page + signature page).
• Extract a continuous segment (for example, pages 10–25).
• Extract everything from a point onward (for example, appendices starting at page 7).

Modern page range strings let you represent these business intents cleanly, without building custom logic for each scenario. If your system is customer-facing—where users type their own ranges—page range rules also become a user-experience feature: the simpler the syntax, the fewer support tickets you get.

What “before” looked like

A lot of older implementations treated extraction as a hard-coded action:

• Store “page 4” as the signature page for one template.
• Write a one-off rule for each document type.
• Re-run extraction manually when templates change.

That approach breaks down as soon as page counts vary, documents merge, or a form adds a new section.

What “today” looks like

A current approach treats page ranges as a small language you generate (or accept from users), validate, and pass to the API. You build reusable patterns like:

• “First five pages” for standard document headers.
• “From page 7 onward” for long appendices.
• “Specific pages” for checklists or approval pages scattered throughout the file.

This upgrade sounds small, but it’s the foundation for scalable extraction.

Reusable Page-Range “Recipes” You Can Use Everywhere

The page range syntax supports common patterns in a condensed, readable way. Below are the practical “recipes” you’ll reuse across projects.

Choose specific pages with commas

Use commas to list exact pages:

• 1,2,5

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.

Choose multiple page ranges with hyphens and commas

Use hyphens for ranges and commas to combine them:

• 2-4,7-9

This is the most common pattern in operational work: “grab the first section, skip the middle, then grab a later section.”

Use a leading hyphen for “from the start to page N”

Use a leading hyphen to represent “from the beginning through page N”:

• -5

This is extremely useful when the “front matter” is consistent while the rest of the document varies.

Use a trailing hyphen for “from page N to the end”

Use a trailing hyphen to represent “from page N through the final page”:

• 7-

This supports the classic “appendix starts here” or “everything after the summary” workflow without needing to know the final page count up front.

Watch out for page-number indexing in examples

Some API samples show page-range strings that include 0 (for example, strings like 0,2-5,7-). 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.

The safest way to handle this in a real product is:

• Run a short internal test PDF (10 pages is enough).
• Verify which page the API treats as the first page when you request 1 vs 0.
• Decide on one convention in your UI (most users expect 1-based).
• Convert if necessary before sending requests.

This small test prevents the most painful class of bugs: “It extracted the wrong page and nobody noticed until a customer complained.”

Selecting an Output Format: PDF vs JPEG vs PNG

A major evolution in page extraction is that you’re no longer limited to producing only PDFs. The output format you choose determines what you can do next in your workflow.

When PDF output is the right choice

Choose pdf when:

• The extracted pages must remain a document (for printing, signing, archiving).
• You want a single combined artifact to send or store.
• You need to preserve text fidelity and selectable content.

PDF output is best for downstream steps that still operate in “document mode.”

When JPEG or PNG output is the right choice

Choose jpeg or png when:

• You need thumbnails and previews for a review interface.
• A human needs to scan pages quickly without downloading a PDF.
• You’re building a UI that displays pages like images (similar to many document review tools).

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.

A practical example: generate PNG thumbnails for selected pages

If your workflow is “show the reviewer pages 1, 5, and 10 as thumbnails,” you’d set the format to png and request those pages.

Here’s a cleaned-up cURL template (fixing the common quoting/header issues that trip people up):

curl --location --request POST "https://{zohoapis_domain}/pdfeditor/api/v1/pdf/pages/extract" \
  --header "Authorization: Zoho-oauthtoken YOUR_ACCESS_TOKEN" \
  --form 'files=@"/path/to/Sample.pdf"' \
  --form 'input_options={"page_ranges":"1,5,10","format":"png"}' \
  --form 'output_settings={"name":"Thumbnails","single_pdf":false}'

Even when you’re producing images, many teams keep single_pdf explicit in requests for clarity and consistency across code paths.

Packaging the Output: Combine or Split With single_pdf

When your output format is PDF, single_pdf becomes one of the most important controls because it changes how your extracted content behaves in storage and downstream workflows.

One combined PDF with single_pdf: true

Use single_pdf: true when:

• You want one deliverable (for example, SignaturePages.pdf).
• The extracted pages should be treated as a single unit in a process.
• Your next step is sending, signing, or archiving as one file.

This is the “make it easy for humans” choice: one file, one download, one share.

Separate PDFs with single_pdf: false

Use single_pdf: false when:

• Each extracted page must become its own item in a workflow.
• You store per-page artifacts (for example, evidence pages, page-level approvals).
• A downstream system expects one PDF per page.

This is the “make it easy for systems” choice: separate objects that can be tagged, routed, or retried independently.

What changed from older patterns

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 single_pdf and keep your application logic simpler.

Treat Extraction as an Async Job, Not a Synchronous Download

One of the most meaningful shifts in “modern” usage is operational: the extraction request is job-based. 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.

Why async matters in production

If you try to keep a request open until extraction completes, you invite failures:

• HTTP timeouts under load
• inconsistent performance across large files
• poor user experience when network conditions vary

Async job handling avoids those problems and fits neatly into queues and background workers.

The standard lifecycle: submit, poll, download

A practical workflow usually looks like this:

1. Submit an extraction job (PDF + page ranges + output settings).
2. Receive a response indicating the job is in progress, along with a status check URL.
3. Poll the status URL on a schedule (with backoff).
4. When successful, retrieve the download URL and fetch the output.

This model scales cleanly: you can process many documents without tying up web threads or blocking user sessions.

What changed from “before to today”

Before, developers often wrote “single-shot” flows: call extraction, wait, download. Today, reliable implementations assume a job lifecycle from the start and design around it.

That changes where you put logic:

• extraction becomes a background task
• the UI shows “processing” states
• you store job metadata and outcomes for auditing

In other words, extraction becomes a true workflow step instead of a one-off utility call.

Building a “Recipe-Driven” Extraction Layer in Your App

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.

Start with a small set of business recipes

Most teams can cover their needs with a handful of templates:

• Front matter: -N (first N pages)
• Appendix: N- (from N to end)
• Known pages: A,B,C
• Known ranges: A-B,C-D

Then you map each document type to a recipe rather than a rigid list of page numbers.

Validate and normalize page-range input

Whether your range is generated or user-entered, validation prevents silent failures and wrong-page extraction. Basic checks include:

• only digits, commas, and hyphens
• no “reverse ranges” (like 9-7)
• no duplicate separators
• within expected bounds if you know page count

Normalization is also helpful: remove spaces, standardize commas, and ensure the string is clean before calling the API.

Make indexing decisions explicit

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’t mix conventions inside your system.

This is one of those “you only learn it the hard way” lessons: indexing ambiguity causes the most damaging extraction bugs.

Operational Best Practices for Reliability

Extraction is easy to demo and surprisingly easy to break at scale. These practices make the difference between a script and a service.

Use backoff when polling job status

Polling too aggressively can waste resources and increase the chance of transient failures. A simple pattern is:

• poll quickly at first (for small PDFs)
• slow down if the job takes longer than expected
• stop after a reasonable timeout and mark the job as failed for review

Persist job state for retries

Store:

• job identifier (or status URL)
• requested page ranges and settings
• timestamps (submitted, completed)
• final output reference (download URL or stored artifact ID)

If a worker restarts, you don’t want to lose track of jobs in progress.

Keep outputs traceable

Name outputs with meaningful identifiers (document ID, timestamp, workflow step). This makes auditing and debugging dramatically easier, especially when customers say “I got the wrong pages.”

Choose output format based on downstream needs

A current design chooses output format intentionally:

• pdf for signature packets, customer deliverables, archives
• png/jpeg for previews, reviewer UX, page thumbnails

When format matches the workflow step, you avoid conversion steps later.

The Takeaway: Page Ranges Are Now a Workflow Design Tool

The biggest difference between “before” and “today” isn’t that extraction exists—it’s that extraction is now sophisticated enough to serve as an automation primitive:

• Page-range recipes express real business intent.
• Multiple output formats let you build both document pipelines and visual review experiences.
• Async job handling makes extraction safe at scale and friendly to modern architectures.

If you build your extraction feature around reusable range patterns, deliberate output formats, and a job-based lifecycle, you’ll end up with a system that survives template changes, supports high volume, and feels fast and reliable to end users.

© Image credits to Steve Johnson