BASALT · JOURNAL
The PDF jobs that keep interrupting your actual work
Nobody's job is PDF work. The job is the filing, the report, the transaction, and the PDF work is the tax you pay in the last hour before it goes out. That hour is where documents get combined in the wrong order, where a scan turns out not to be searchable, and where a file leaves carrying something nobody looked for.
Most people assemble their PDF tools for Mac out of whatever was nearest: Preview for two things, a website for a third, a command line tool someone recommended, and a subscription for the one operation nothing else does. This is a look at the jobs themselves and what each actually requires.
Combining exhibits into one document
The naive version is concatenation. The real version has to decide what happens to everything that is not page content.
Each input carries its own document information dictionary and XMP packet, and the combined file gets one of them, usually the first document's, so the output can end up labeled with an author and title from an unrelated source. Each input carries its own bookmark outline, and a correct merge re-parents all of them under a new root and rewrites every destination to the new page positions. Each input can carry embedded files, so a forty exhibit bundle inherits forty sets of attachments that were never reviewed together.
Form fields with the same name across two inputs will share a value unless renamed, optional content groups from different sources land in one /OCProperties dictionary, and page sizes and rotations have to be preserved or normalized deliberately. A merge is the operation most likely to introduce hidden material into a document, because it aggregates the hidden material of everything that went into it.
Splitting a bundle back apart
Extraction is the mirror problem and the failure is quieter. Pull pages 40 to 90 out of a bundle and the extract should carry the bookmarks covering those pages with destinations rebased, the annotations attached to those pages, and nothing referencing pages that are gone.
What usually arrives is an extract with no outline, which is why so many fifty page excerpts have no navigation. Named destinations that lived in the /Dests name tree may not be carried across, so links that look fine do nothing. Splitting also has to decide whether the extract inherits the parent's metadata and attachments, and frequently it should not, because the parent was a working bundle and the extract is going to an outside party.
Making a scan searchable
Recognition puts a text layer under the image: real glyphs drawn in rendering mode 3, positioned to line up with the picture of the words. That is what makes a scan searchable across a folder instead of page by page.
Two things follow. The file now holds two independent copies of every word, the pixels and the glyphs, which matters the moment anything on that page needs removing, because destroying pixels without editing glyphs leaves the words fully extractable. And recognition is a heavy, document-wide operation on material that is very often confidential, which is exactly the wrong kind of file to upload to a website. The risk of cloud PDF tools is worth reading before a scanned client file goes anywhere.
Numbering a production
Bates numbering is a stamp with rules: a prefix, a fixed digit count, a starting number, a consistent position, and continuity across every document in the set. The number becomes the identifier the whole matter uses afterward, in the privilege log, in deposition, in every later reference to a page.
The requirements are unglamorous and unforgiving. Numbering has to continue across a set of files rather than restarting per document, rotation must not put the stamp in the wrong corner, the stamp must not land on content, and regenerating a production after a correction has to yield the same numbers for the same pages. None of this is hard; it is simply not something a general purpose viewer does.
Cleaning a file before it goes out
This is the job people know they should do and skip, because doing it properly means touching five structures.
Metadata lives in two independent stores, the document information dictionary and the XMP packet, and clearing one leaves the other. Embedded files sit in the names dictionary or in file attachment annotations, invisible during page review, sometimes carrying the spreadsheet a chart was built from. Optional content groups that are switched off are invisible on screen and in print while their text extracts normally, which makes a hidden layer a real leak route. Bookmark titles are plain text in the outline and often name people or matters. Prior revisions retained by incremental updates can hold the pre-edit state of every page.
Each is a separate operation on a separate object, and doing four of the five is not most of the job. The output also has to be written as a single generation, because every removal is undone if the earlier revision is still appended in the same bytes. What a PDF still carries after you think you cleaned it is the full inventory, and how to see everything a PDF is actually carrying covers finding it in a specific file.
Removing text permanently
Redaction is its own job and the only one where a mistake is not recoverable, because the file is already with the other side. Covering text with a black rectangle leaves the glyphs in the content stream underneath, and removing glyphs from the visible run while leaving /ActualText in place publishes the words to every extractor. A scan needs its pixels destroyed and re-encoded, not painted over, and its OCR layer edited to match. The result needs checking by extracting text from the written file rather than assuming, which is a step in its own right.
Why the tool sprawl is the actual cost
Consider a filing week. Fifteen documents arrive from three sources. They need combining in a specific order, the scanned ones need recognizing, two need pages pulled out, the set needs numbering, three pages need redacting, the outline needs fixing because the merge broke it, and everything needs cleaning before it goes.
Done across four tools and a website, that is a document copied between applications eight times, each copy a chance to send the wrong version, each application applying its own metadata, and one hop putting a confidential file on someone else's server.
The version that goes wrong least is the one where the document does not move: several files open as tabs in one window, jobs applied in place, every operation writing a new file so the original is always there to return to, and the inspection step available at the end. That is a workflow property, not a feature list, which is why an Acrobat alternative on the Mac is worth judging on how the work flows.
Frequently asked questions
What PDF tools do I actually need on a Mac?
The recurring jobs in professional document work are combining files, splitting or extracting pages, reordering and rotating, making scans searchable, applying Bates numbers to a production, redacting text so it is removed rather than covered, and cleaning metadata and hidden data before sending. Preview covers viewing, annotation, and simple page reordering. Everything else, including redaction that actually removes content, needs a tool that parses the file structure.
Can Preview merge and split PDFs?
Preview can combine documents by dragging pages between thumbnail sidebars and extract pages by dragging them out, which is adequate for small, low-stakes jobs. It gives you no control over what happens to bookmarks, metadata, embedded files, or form fields during the operation, so merged output frequently loses navigation and inherits an unrelated document's metadata. It is a viewer with page-level conveniences, not an assembly tool.
Is it safe to use free PDF websites for work documents?
No, not for confidential material. Uploading a document puts the file, its metadata, and any embedded attachments on infrastructure you do not control, subject to whatever retention and access policy that service applies, and for privileged or regulated material the upload itself can be the disclosure. These operations are all local by nature, so there is no technical reason the document has to travel.
Why do my bookmarks break when I merge PDFs?
Because a merge has to rewrite every bookmark destination to point at the pages' new positions in the combined document, and many tools do not. Bookmarks target either a specific page object or a name in the /Dests name tree, and both references become wrong once pages move. The result is an outline that displays correctly but sends you to the wrong page or nowhere at all.
Does making a PDF searchable change the pages?
Recognition adds an invisible text layer under the existing page image rather than altering the visual appearance: real glyphs drawn in rendering mode 3, positioned over the picture of the words. The page looks identical and is now searchable. The consequence to remember is that the file then holds two copies of every word, so any later removal has to address both the image pixels and the text layer.
What should I check before sending a PDF outside my organization?
Check both metadata stores, the information dictionary and the XMP packet, then enumerate embedded files, look for optional content groups that are switched off, read the bookmark titles for names or internal shorthand, check whether the document carries prior revisions from incremental updates, and confirm any redactions by extracting text from the final file. Each of those is a different structure, so a clean result on one says nothing about the others.
Do PDF editors modify my original file?
It depends entirely on the tool, which is worth knowing before you start rather than after. Some editors save in place, so a misjudged operation has already changed the only copy you had, and an in-place save is frequently an incremental update that leaves the prior state inside the file. A tool that writes a new file for every operation gives you both an intact original and a clean single-generation output.
What is Bates numbering and why does it need a dedicated tool?
Bates numbering stamps a sequential identifier on every page of a production, with a fixed prefix and digit count, running continuously across all documents in the set rather than restarting per file. It needs a dedicated tool because the requirements are exact: consistent placement regardless of page rotation, no overlap with existing content, and repeatability, so regenerating a production after a correction yields the same number for the same page.
Doing it in Basalt
Basalt puts eighteen tools in one window: redact, merge, split, organize, compress, OCR, passwords, Bates numbering, forms, sign, watermark, images to PDF, procedures, inspect, clean up, compare, scripts, and privilege log. Documents open as tabs in a single window rather than scattering, so the filing week above happens in one place.
Every tool writes a new file, so your original is never modified, and redaction destroys content rather than covering it, with a verifier re-opening the written file using an independent parser to prove the content is gone before anything is saved. The interface links no PDF parser at all; only the sealed engine does, and it holds no network entitlement, enforced by macOS at the code signature level. Check it yourself with codesign -d --entitlements :- /Applications/Basalt.app/Contents/XPCServices/BasaltEngine.xpc. It is a 17 MB download for macOS 13 and later on Apple silicon and Intel, $29 once for up to three Macs, free for 24 hours.
Redaction that proves itself
Basalt destroys the content you mark, then re-opens the file it wrote and proves the content is gone before it saves anything. Your documents never leave your Mac.