Built for the document work between files.

There is a familiar pattern in everyday document work: you already have the files, you already know the result you need, and the only missing step is a small operation. A report needs three pages extracted. Six invoices need to become one archive. A course handout is split across several PDFs. A scanned receipt needs to sit beside a PDF statement. A set of screenshots needs to become a PDF that can be attached to an email.

Those tasks do not necessarily need a full document-production suite. Zippy is designed around that middle ground: a small number of clear operations presented in one workspace, with enough room to see what is happening and a result area that makes the next step obvious.

The studio is intentionally not trying to be every kind of PDF software at once. Its current focus is on useful file-level and page-level operations that map well to browser capabilities.

Merge PDFs is useful whenever several already-finished files belong to the same package. A job application might contain a CV, cover letter, certificates and a portfolio appendix. A supplier archive might contain invoices, delivery notes and a purchase order. A project handoff might contain a report, approval sheet, diagrams and supporting documentation.

It is also useful for long-form reading. Separate chapters, lecture notes or reference PDFs can be placed into one ordered document for a course folder, study pack or personal archive. The same workflow works for books or manuals that arrive as several PDF parts and need to be kept together for easier storage.

Zippy shows the selected files before processing, so the order can be reviewed before the combined PDF is generated. Source files are not rewritten; the tool creates a new document.

Split PDF is the natural fit when one large document contains a smaller subset you actually need. Think of a 70-page report where someone only needs pages 12–18, an invoice bundle where a single record must be forwarded, a manual where only one chapter belongs in a ticket, or a research paper collection where a few pages need to be shared separately.

Page ranges such as 1-3, 5, 8-10 are useful because they describe the intended result directly. The source PDF stays unchanged while Zippy creates a new PDF containing the selected pages in the order you entered.

PDF + images is designed for situations where not everything arrives as a PDF. A signed approval page might be a JPG. A scanned ID or receipt might be a PNG. A chart exported from another tool might be WebP. Meanwhile, the main report is already a PDF.

Instead of converting every image separately first, this workflow lets supported PDFs and images stay together in one ordered build. That can be useful for applications, inspection records, project packs, evidence bundles, product documentation and administrative paperwork.

The idea is simple: treat the mixed files as one document sequence, then create the final PDF once the order looks right.

PDF → PNG is useful when the next destination expects an image instead of a document. A page from a report can become a slide graphic. A diagram can be shared in a message. A portfolio page can be placed into a design board. A screenshot-like preview of a contract page can be used for internal review.

It is especially useful for design, presentation and communication workflows where you do not need the entire PDF represented as one file. Select the pages you need and render them as individual PNG images.

Images → PDF fits the opposite direction. Receipts, photographed notes, scanned forms, screenshots, worksheets and exported graphics often exist as image files before they become a document.

Converting them into a PDF makes the set easier to archive, attach and read as one unit. It is useful for course notes, expense records, signed paperwork, simple portfolios, inspection photographs, batches of receipts and image-based handouts.

Zippy keeps one image per page in the generated PDF, giving the resulting file a predictable structure without altering the original images.

For the current operations, the browser can read files selected by the user, process binary data in memory, render PDF pages and create downloadable results. Zippy uses that model to keep the interaction focused on the active browser session rather than a traditional upload-and-job queue.

The studio uses pdf-lib for creating and assembling PDF documents and PDF.js for reading and rendering PDF pages. This approach is well suited to small and medium document jobs where the browser and device have enough memory for the operation.

Local-first does not make every PDF problem disappear. Very large documents, unusual PDFs, damaged files and password-protected files can still fail. Zippy therefore surfaces processing errors rather than pretending that every input is valid.