PDF to image sequence

Provide the number of pages in the PDF and choose PNG or JPG; the result contains one predictable filename for every page. The sequence uses enough leading zeros to keep names in the correct order when sorted as text. It does not upload, inspect, or convert a PDF, making it useful for planning exports, validating conversion results, and preparing downstream jobs before image files exist.

Plan a complete page image sequence before conversion

PDF conversion pipelines often need to know their expected outputs before a renderer begins. A storage job may need destination keys, a database may need one row per page, or a test may need to check that no converted image is missing. Enter the PDF page count and select either PNG or JPG to receive a complete filename manifest. Each name starts with page-, followed by its one-based page number and the selected extension. The generator does not need the PDF itself because its purpose is planning names, not reading or rendering document content. This separation makes the result quick, reproducible, and safe to use during an earlier workflow stage. A twelve-page document produces names from page-01 through page-12, while a document with hundreds of pages automatically uses a wider numeric field. The returned page count and format also make the manifest self-describing, so another service can confirm that it received the sequence requested by the caller.

Keep filenames correctly ordered in storage and file browsers

Unpadded page names create a subtle ordering problem: ordinary text sorting places page-10 before page-2. This capability avoids that issue by calculating the width of the highest page number and left-padding every number to the same width. Nine pages need one digit, twelve pages need two digits, and one hundred twenty pages need three digits. As a result, the returned array remains in page order and the filenames also remain correctly ordered when listed by object storage, archive tools, command-line utilities, or desktop file browsers. Numbering begins at one because it represents the page numbers readers and PDF tools normally display, rather than zero-based array indexes used inside software. The selected extension is applied consistently to every entry and is restricted to the two supported output targets, png and jpg. Rejecting any other value prevents a manifest from promising files that the defined workflow does not support and helps callers catch spelling mistakes before starting more expensive conversion work.

Use the manifest as a deterministic workflow contract

The result is designed to connect independent stages of a document workflow. A conversion worker can claim one filename per page, an upload stage can reserve matching object keys, and a validation stage can compare the files actually produced with the expected list. Because the algorithm uses no network access, current time, randomness, or document metadata, identical inputs always produce identical output. That property is valuable in automated tests, retryable jobs, content-addressed build systems, and audit records. The page count is limited to ten thousand so a malformed request cannot allocate an unbounded array or overwhelm a browser with output. The capability reports invalid page counts and unsupported formats as input errors instead of silently correcting them, which keeps the contract explicit. Use $0.002 when calling it through the API, or run the same deterministic logic in the browser. Remember that this tool lists planned filenames only: a separate PDF rendering capability must create the corresponding image bytes, and its observed output can then be checked against this manifest.