Covering is not removing: what Novus PDF Studio can actually take out of a document

The most dangerous thing a document tool can do is make you believe something is gone. Everything else it gets wrong, you find out about: a misaligned field looks misaligned, a missing signature is missing, a bad export refuses to open. But a white rectangle drawn over an account number looks completely final on screen, and the moment the file leaves your hands you have no way to check. The failure is silent, it is downstream, and it is usually discovered by somebody who was not supposed to see the number.

Novus PDF Studio has two halves, and the line between them is exactly this line. The editor adds: every field, mark, signature, highlight, and white-out is drawn on top of the page. The page tools at /tools are where content genuinely leaves the file. This article is about where that boundary sits, why we drew it where we did, and why the product does not ship a button called Redact even though shipping one would have been easy and would have made the feature list look better.

Start with why the additive model exists, because it is not a shortcut — it is the product's best property. When you fill a form in PDF Studio, what you place is not typed into the document the way a word processor types into a paragraph. Text values, numbers, date-style entries, check and cross marks, and signatures all arrive as editable layers sitting above the page. You can move them, resize them, duplicate them, restyle the font, size, colour, and position, and delete them.

That model is what makes the tool forgiving. A typo is a two-second correction rather than a reprint. A check mark that landed one row too high gets dragged down. A signature drawn too large for the line gets resized rather than redrawn. And it is what allows the AI field scan to be useful without being authoritative: every suggestion the scan makes lands as a layer you can correct, and you can clear only the AI-placed fields while keeping the ones you added by hand. A tool that was confidently wrong and uncorrectable would be worse than one that is tentatively right and easy to fix.

The same mechanism, though, is the source of the misunderstanding this whole article exists to clear up. If your name is a movable object rather than baked-in ink, so is the white rectangle you dragged over a paragraph. Both are things drawn on the page. The interface does not distinguish between "content I am adding" and "content I am hiding", because at the level of the mechanism there is no distinction to draw. That is fine for a signature. It is not fine for a bank account number.

The markup in PDF Studio includes highlight and white-out. Both are exactly what their names say: they change what is drawn on the page. A white-out rectangle is an opaque shape placed above the region you want hidden. On screen, and on paper, it does its job — the text underneath is not visible.

What it does not do is remove the underlying content from the document. True redaction, in the sense that a security professional means it, deletes the text objects rather than obscuring them, so that the information is not present in the file at all. That is a materially stronger guarantee than covering, and it is one this product does not currently make. The hub documentation says so, the launch note says so, and this article says so, because the whole value of the claim lies in it being consistent everywhere.

It is worth sitting with the practical consequence rather than moving quickly past it. If a document has to be sent, and one line on a page must not reach the recipient, then covering that line with a rectangle is not the operation you want, no matter how convincing it looks in the preview. The visual result and the security result are two different results, and only one of them is verifiable by looking.

This is the decision the rest of the article hangs on, and it went the way it did for one reason: a label is a promise. A control named Redact tells the user that the content is gone. If the implementation underneath is a rectangle drawn on top of the page, then the label has manufactured exactly the false confidence that gets a document sent when it should not have been. That same rectangle, labelled White-out, is safe — the name tells the truth about the mechanism, something was painted over the page, and the user calibrates accordingly. The identical implementation, relabelled Redact, is actively dangerous.

That inversion is worth stating clearly, because it runs against the usual instinct. In most of a product, a better name is a nicer name. In a security-adjacent feature, the better name is the one that understates. The most harmful version of this feature is not the missing one — it is the present one that overclaims, because the missing feature simply sends the user somewhere else, while the overclaiming one sends the user forward with a file they now trust.

There is a second reason, which is about what we would owe you if we did ship it. A redaction guarantee is not a feature you implement; it is a claim you are then held to, forever, across every document shape a user can bring. Getting it right means removing the underlying content objects rather than drawing over them, and being able to demonstrate on the exported file that they are not there — not just that they are not visible. Until we can do that and stand behind it on documents we have never seen, the honest position is the one the product takes now: highlight and white-out are markup, they are named as markup, and redaction is not on the list of things this tool claims.

That is not a promise that it is coming. It is a description of what would have to be true first.

So what does work? The page tools. Split breaks a PDF into separate documents or extracts a page range, and the pages you did not extract are not in the output file. Organize reorders, duplicates, rotates, and removes pages before export, and a removed page is removed. These are the operations in PDF Studio where content actually leaves the document rather than being covered up inside it.

That points at a practical pattern which is better than most of what people attempt with markup. If you have a twelve-page packet and the recipient needs pages three through five, the reliable move is to split out pages three through five and send that file — not to send all twelve with the other nine obscured. The first version cannot leak the other nine, because they are not there. The second version depends entirely on your covering having been thorough, on every page, in every place, which is a standard nobody meets under time pressure.

The honest limitation is granularity. This works at page level and only at page level. It cannot take one line off a page that otherwise has to be sent, and there is no combination of the seven page tools that adds up to line-level removal. If your problem is a single sensitive line on a page you must deliver in full, PDF Studio does not solve it, and the following section is about what to do instead.

The most dependable way to keep information out of a PDF is not to put it in. That sounds like a dodge and is in fact the professional answer. Once content has been flattened into a page description, taking it back out reliably is a specialist operation with a verification burden attached. Producing the document without the sensitive line in the first place costs nothing and has no failure mode.

In practice this means regenerating the export from whatever produced the PDF with the field excluded, using the version of a template that does not include the appendix, or asking the sender for the extract rather than the whole record. When you are the one generating the document, the decision point is upstream of the PDF entirely, in the system that renders it. When you are not, the request is usually easier to make than the workaround is to perform.

Where that is impossible and a page has to go out with something on it that must not be readable, the answer is a purpose-built redaction tool that removes content objects and can demonstrate it, not a rectangle in any application. We would rather point you there than take the work and be approximately right about it.

The Protect tool encrypts a PDF with AES-256 and can set viewer permissions, producing a protected copy while leaving the source untouched. The encryption is real: without the password, the file does not open. For sending a benefit form, an invoice carrying account numbers, or any record you would not want a stranger reading if the message went to the wrong address, that is a sensible and meaningful safeguard.

The sentence people get wrong is what it protects. A password controls who can open the document. It does not control what is inside it. Everyone you give the password to sees the entire file, every page, including the parts you were uneasy about. Encryption is not a substitute for removal and it is not a partial-visibility mechanism — there is no version of a PDF password that shows a recipient some pages and withholds others. If a particular reader must not see a page, that page has to be out of the file before you protect it, not hidden behind the password.

It is also worth distinguishing the two things the Protect tool can set, because they are not equally strong. The password is enforced by cryptography. Viewer permissions are a flag in the document that a cooperating reader honours; they express an intention about what should be allowed rather than making it impossible. Treat the password as the security boundary and the permissions as a courtesy notice, and you will not be surprised later.

Unlock is the reverse operation and is deliberately narrow: it removes a password you already know from a file you are authorised to open. It is not recovery and it is not cracking, so there is no route back from a password you have lost — which is precisely why the sharing habit is to keep an unprotected master copy of your own. The step-by-step version of that habit, including choosing a passphrase and sending it through a channel separate from the file, is in the protect tutorial rather than repeated here.

A page that lists only strengths is advertising, so here is the one that is easiest to overlook. Novus PDF Studio does not clean document metadata. Whatever the source file carried in its document properties travels into the export with it, and none of the careful work you did on the visible page touches that.

This matters because metadata is exactly the category of information that survives a careful review of the thing you were looking at. You checked every field, verified the amounts, confirmed the signature sat on the line, and exported — and the visible document is now correct. What was never on screen was never checked. Naming this is more useful than a reassuring silence would be, because a user who knows the tool does not scrub metadata can decide whether that matters for the document in front of them, and a user who assumes it does cannot.

The same honesty applies to the rest of the boundary. PDF Studio is not a compliance platform, and adding a password does not satisfy any legal or regulatory standard by itself. It is not a secure document vault; your files do not live in it between sessions. It does not run optical character recognition on scanned paper, so a photograph of a form can be annotated and signed but not converted into selectable text. And compression and format conversion are not part of it — those are a different job, and one Novus Convert is built for.

Most of the confusion this article addresses comes from a single question — how do I get rid of this? — having five different correct answers depending on what "this" is and who must not see it. Sorting the question before reaching for a tool prevents nearly every mistake in the category.

What exists is the fill-and-sign editor and seven page tools: merge, split, organize, rotate, page numbers, protect, and unlock. They share the editor's rendering and export pipeline, so a document that comes out of a page tool and one that comes out of the editor are produced the same way. What does not exist is compression, format conversion, redaction, and metadata cleanup, and those absences are choices rather than a roadmap with a delivery date attached.

The reason to write a whole article about the difference between covering and removing, rather than leaving it as a line in the documentation, is that this is the one gap in the product where not knowing about it has a real cost. Every other limitation announces itself: you look for a compress button, you do not find one, you go elsewhere. This one does the opposite. It gives you a satisfying result on screen and lets you find out later.

If you want the reference for what the editor and the page tools do today, that is Novus PDF Studio, and the route-by-route inventory is Tool maps. If you want the sharing habit in full, Protect a PDF with an AES-256 password walks it. And if what you actually needed was to send part of a packet rather than all of it, Split a PDF and extract page ranges is the two-minute version of the most useful idea in this article.