PDF booklet imposition calculator for saddle-stitch printing
The PDF booklet imposition calculator turns a document page count into the exact order needed for saddle-stitch printing.
Run — free
It adds the minimum permitted blank padding, then lists every physical sheet with its front and back left-to-right positions. The result is deterministic and easy to feed into a print workflow, inspect during preflight, or use as a reference when rearranging pages. No PDF upload is required because the calculation depends only on the number of source pages.
Why booklet page order looks unusual
A saddle-stitched booklet is made from sheets that are printed on both sides, folded through the center, nested, and stapled along the fold. That physical construction changes the order in which pages must appear on the flat sheets. The first visible spread is not simply pages one and two: on the outermost sheet, the highest imposed position sits beside page one on the front, while page two sits beside the next-to-highest position on the back. Moving inward repeats the pattern until the center spread is reached. This calculator performs that pairing for every sheet and labels each front and back position from left to right. The sheet list starts with the outermost sheet, matching the order a prepress operator commonly uses to inspect a booklet. Numbered positions refer to the original PDF pages. A position marked as blank is an added padding page, not a missing source page. The result describes reader-order saddle-stitch imposition; it does not alter, upload, or render the PDF itself.
How blank padding is validated
Every folded sheet contributes four booklet pages: two positions on the front and two on the back. The imposed page count therefore must be divisible by four. When the source page count is not already a multiple of four, the calculator appends the minimum number of blanks needed to reach the next valid total. A ten-page PDF, for example, needs two blanks and becomes a twelve-position booklet. The max_blank_pages input controls whether that adjustment is acceptable. Its default of three permits every possible remainder, while a lower value lets a production rule reject documents that require more padding than expected. Set it to zero when upstream files must already contain a complete signature. If the required blank count exceeds the allowance, the request returns an input error instead of presenting an impossible or unauthorized layout. Padding is always appended after the last source page, so blank positions naturally appear near the outside of the imposed sequence. The response reports both the original and imposed counts, making the adjustment explicit and auditable.
Using the sheet plan in a print workflow
Read each sheet entry as a physical sheet before folding. The front object gives its left and right page positions, and the back object does the same for the reverse side. The exact duplex flip setting, rotation, creep compensation, bleed, and printer marks depend on the press and finishing workflow, so they are intentionally outside this page-order calculation. Before a production run, compare a small folded proof with the returned sequence: confirm that page one begins in the expected place, consecutive pages meet after folding, and any blank pages land at the end of the reader-order document. Software teams can use the same response to build page-reordering arrays, preflight reports, or operator instructions without reimplementing booklet arithmetic. Because the output uses explicit blank objects rather than ambiguous zero or null values, downstream code can distinguish padding from numbered pages safely. The operation is pure arithmetic, uses no network access, and returns the same result for the same inputs. API automation costs $0.002 per request, while the browser version can run locally for quick planning.
What you can do with it
Prepare a short-run booklet
Calculate the front and back page positions before rearranging a brochure for duplex saddle-stitch printing.
Validate a prepress export
Compare an imposed file against an independently calculated sheet plan and confirm that blank padding is allowed.
Automate print job instructions
Generate a deterministic sheet-by-sheet plan for a workflow, job ticket, or PDF page-reordering tool.
FAQ
What does the API request cost?
Each request costs $0.002. The same deterministic calculation is also available in the browser.
Why must the imposed page count be divisible by four?
One folded, duplex-printed sheet creates four booklet page positions, so a saddle-stitched booklet can only contain a multiple of four imposed positions.
Where are blank pages added?
Blank pages are appended after the final numbered source page before the sheet order is calculated.
What happens when max_blank_pages is too low?
The request returns an invalid input error explaining how many blanks are required and how many were allowed.
Does this tool modify or upload my PDF?
No. It receives only a page count and returns a layout plan; it does not read, store, render, or rewrite a PDF.
Does the output include printer rotation and duplex flip settings?
No. Those settings vary by printer and workflow. The output covers the logical left-to-right page order for each sheet side.
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/pdf/booklet-layout \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"page_count":10}'const res = await fetch("https://api.kit.forhosting.com/pdf/booklet-layout", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"page_count": 10
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/pdf/booklet-layout",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"page_count": 10
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/pdf/booklet-layout", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"page_count":10}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"page_count":10}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/pdf/booklet-layout", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"page_count": 10
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "pdf.booklet_layout",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Limits
max_pages | 100000 |
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |