Documenting the steps to use Alternate Mix PDF means writing a short, repeatable procedure that names the two input files, fixes the A1, B1, A2, B2 interleaving rule, and records the browser-based output you expect. The tool combines two local PDFs by alternating their pages in reading order and appending any unmatched tail pages from the longer document, which makes the workflow easy to describe because every step maps to a visible action in the interface. Your documented procedure should cover three things: what files qualify as inputs, what order the interleaved output must follow, and what to verify before you trust the downloaded result. Recording these checkpoints turns a one-off task into a procedure you can hand to a colleague, repeat on a future scan batch, or paste into a runbook for your team. Because the mixing happens entirely in your browser tab with no upload to Lizely, the documented procedure also doubles as a privacy note showing which files never leave the device.
What a Runbook-Style Procedure Should Capture
When readers search for how to document the steps they use with a tool, they usually want a written record that survives them — something a coworker can follow without watching over their shoulder, or something they can re-open months later when the same task recurs. For Alternate Mix PDF, that record has a narrow scope because the tool has a narrow scope. It accepts exactly two PDFs, applies exactly one ordering rule, and produces exactly one downloadable file. Your procedure document therefore needs to spell out the inputs, the rule, and the verification, not invent extra controls the interface does not expose.
Write the procedure so each line corresponds to one user action. Resist the temptation to add click-by-click phrasing in the text. Instead, name the file you would pick, the button you would press, and the visible result you expect. A useful test is to read your procedure aloud while a second person follows it on a different machine; if they hesitate anywhere, that sentence is missing a checkpoint and needs to be expanded. The same test catches missing prerequisites, because a new reader always stumbles on the first prerequisite the original writer took for granted.
Inputs, File Names, and Limits Worth Recording
Every runbook should begin with the prerequisites because they determine whether the tool can complete the task at all. For Alternate Mix PDF, the prerequisites are bounded and specific, and your procedure should state them as a short block before the numbered steps.
- Two non-empty PDFs. The tool rejects empty files with a visible error, so name in your procedure which files you intend to use as PDF A and PDF B.
- 25 MiB per file. The size cap applies to each input separately, not to their combined output. A large A plus a small B can both pass while a slightly larger A or B fails on its own.
- Pre-sorted internal order. The tool does not reverse either PDF. If a scanner produced one of the two documents in reverse order, that source has to be reordered first with a dedicated tool, then named again in the procedure.
- Read access on the device. Because loading, copying, and serialization all run in one browser tab, the practical memory footprint can exceed the two source file sizes while the output is being built.
A useful table to include inside the procedure is the inputs-to-outputs expectation, because it is the single source of truth readers will check their work against. The tool reports the page count of each input and the total output count, and the total output count by construction must equal the sum of both inputs.
| Scenario | PDF A pages | PDF B pages | Output page count | Expected sequence |
|---|---|---|---|---|
| A longer than B (confirmed example) | 3 | 2 | 5 | A1, B1, A2, B2, A3 |
| B longer than A (confirmed example) | 1 | 3 | 4 | A1, B1, B2, B3 |
| Equal length, A first | 4 | 4 | 8 | A1, B1, A2, B2, A3, B3, A4, B4 |
| Minimum one page each | 1 | 1 | 2 | A1, B1 |
The pattern is well-established and visible in the interface: when one input runs out of pages first, the remaining pages from the longer document are appended in their original order, never reversed, never interleaved further. Note also that the first selectable file is always A, so swapping which file you assign to slot A versus slot B rewrites the entire sequence under the same logic. Your procedure should call out that asymmetry because it is the single biggest source of "wrong first page" reports.
Documenting the Exact Mixing Procedure
This is the section you would lift into a runbook, a wiki page, or a printed cheat sheet. Write it as an ordered list of actions, the way the user will actually click through them, and label each step with what the interface will show once the step succeeds. The number of steps stays small because the tool has a narrow interface.
- Open the Alternate Mix PDF tool in your browser so both files remain local to your device throughout the workflow.
- Choose PDF A from the first selector. The first selectable file always supplies the first output page, so document which file plays that role for each batch you process.
- Choose PDF B from the second selector. Confirm both selections are non-empty and below 25 MiB before continuing.
- Verify in your runbook that each source is already in the intended internal order. If a scanner produced a reversed stack, reorder that source separately before this step.
- Click Alternate and mix PDFs. The tool loads both files, builds an A-then-B sequence for every shared index, and appends the longer document's remaining pages.
- Read the result line. It reports the page count of each input and the total output count, which by construction must equal the sum of both inputs.
- Download the result. The new filename combines the cleaned source names and adds -alternated.pdf, while the original files remain unchanged on your device.
Each step in this list is also a verification checkpoint. If step 6 shows any mismatch — for example, the total output count does not equal A plus B — stop the procedure, do not download, and capture the names of any encrypted, damaged, oversized, or incorrectly labeled inputs for the runbook log. Encrypted, damaged, unsupported, oversized, and incorrectly labeled files each produce a visible error, and password protection is not bypassed, so naming these failure modes up front prevents repeat retries.
What to Verify in the Downloaded Output
A documented procedure is incomplete without an output check, because the tool's interleaving rule is fixed but the inputs vary. Open the downloaded PDF and skim three checkpoints that match the order you wrote down: the first page should be A1, the second should be B1, and the final pages should be the tail pages from whichever document was longer. If those three checkpoints hold, the rest of the sequence is structurally sound because every shared index was processed A-then-B and every tail page was appended in its original order.
Pages from each source retain their own page-box dimensions, rotation, vector drawing, text, and embedded raster content, so the output will not look uniform if A and B were scanned at different sizes. The procedure should state this expectation explicitly so a reader does not flag it as a bug. Forms, bookmarks, outline destinations, scripts, attachments, and cross-document links are not guaranteed to survive page copying with the same semantics, so any document that relies on those interactive features should be inspected manually after mixing and noted in the runbook as a follow-up. The tool does not force every page to the first document's size, stretch content, rasterize text, or insert blank separator pages, which is exactly the behavior you want for an interleaved scan.
If you are documenting the procedure for audit or compliance purposes, include the line that loading, copying, serialization, and download creation happen inside the browser with no upload to Lizely. That single fact closes a common reviewer question before it gets asked and confirms that the privacy posture of your documented procedure matches the tool's actual behavior.
Edge Cases and Gotchas Worth Naming in the Procedure
The tool surfaces a visible error for the failure modes listed above, but the procedure is stronger if it names them up front so the next operator does not waste time retrying. Three other edge cases are worth recording because they change the visible behavior of the interface without producing an error.
- Choosing a replacement file for either input clears the old output, so a partial mix is never silently saved under the wrong filename. Your procedure should note this so a reader who picks the wrong file and then reselects does not think the previous output is still valid.
- Job identifiers prevent a slower earlier operation from replacing a result made from newer files, which matters when the same browser tab is reused for several batches in a row. Mention this so a reader understands why a delayed result cannot overwrite a newer one.
- Interactive structures such as form fields, bookmarks, outline destinations, scripts, attachments, and cross-document links may not survive page copying, so the procedure should instruct the reader to reopen any such document manually after download.
These notes do not change the procedure; they protect it. A reader following the runbook will not be surprised by the error message, by a disappearing result, or by missing form fields after download. Keep irreplaceable originals outside the browser workflow until the downloaded result has been verified, and close other heavy tabs if the device is memory constrained, since the practical memory cost during mixing can exceed the two source file sizes when the new serialized result coexists with them.
Extending the Procedure With Related Tools
Some procedures cannot stop at interleaving because the inputs arrive in the wrong shape. A scanner that produces one stack in reverse order needs a dedicated reorder step before mixing; a batch that should simply be concatenated needs a different tool entirely. Rather than overloading the Alternate Mix PDF procedure with those cases, link to the right tool from inside the runbook so the reader knows when to branch. The procedure stays narrow, but the reader gets a map.
For example, if the goal is plain front-then-back concatenation rather than alternating pages, the right tool is Merge PDF, which combines several PDFs in the order you specify without interleaving. If a single page within the eventual output needs to be removed, Delete PDF Pages handles the trim after the alternating step. For a deeper decision aid on whether interleaving is the right choice at all, the decision guide for alternate PDF pages covers the same inputs and outputs from a different angle and can sit at the top of your runbook as a triage step. Keep these references inside the procedure so a future operator can branch without leaving the runbook.
Documenting the steps you use to interleave two PDFs is mostly a matter of stating a fixed rule — A first, B second, tail appended from whichever is longer — and a fixed set of file limits. Once those are written down, the procedure fits on a single page, reproduces the same output every time, and survives being handed to someone who has never opened the tool. That is the point of writing it down at all.