DEV Community: AngelBot AI

Your PDF Viewer Runs in the Browser. Does That Actually Make It Secure?

AngelBot AI — Thu, 29 Oct 2026 11:22:02 +0000

Moving document processing into the browser can reduce server-side exposure.

But there is a difference between processing a document locally and building a genuinely secure document workflow.

That distinction matters when your application handles contracts, financial records, employee documents, legal evidence, or other sensitive information.

Let's look at what client-side PDF processing changes, what it does not change, and what developers should verify before calling a document viewer secure.

What client-side processing actually means

In a traditional architecture, a user uploads a PDF to a server, the server processes it, and the application returns a result.

Depending on the system, that process might involve temporary files, document conversion services, storage systems, logging, or third-party APIs.

With a client-side architecture, some or all document processing happens inside the user's browser.

That can eliminate the need to upload a document to your application server for those particular operations.

However, client-side processing is an architectural choice, not a complete security guarantee.

The application can still introduce risks through its own code, dependencies, permissions, browser environment, and data flows.

Find out where the document actually travels

Do not rely on a product description that says processing happens locally.
Inspect the implementation.

Ask questions such as:
Is the original PDF uploaded to an application server?

Does the application send document content to an external API?

Are extracted text, annotations, or search queries transmitted anywhere?

Are document contents included in error reports or analytics events?

Does the application use remote conversion or OCR services?

Are temporary copies written to storage?

The answers depend on the actual implementation and configuration.
Browser developer tools can help you inspect network requests during document loading, search, annotation, and export. For a serious security review, combine that inspection with source-code review and testing across all relevant workflows.

A quiet network tab during initial loading is not proof that no data leaves the browser later.

Remember that the browser is not a trusted vault.

Local processing changes where computation happens, but it does not make the user's environment invulnerable.

A malicious browser extension, compromised device, injected script, or cross-site scripting vulnerability may expose data accessible to the page.
Third-party JavaScript deserves particular attention. Code executing in the same page context may have access to application data, depending on how the application is designed.

For sensitive document applications:
Minimise unnecessary third-party scripts.
Apply an appropriate content security policy.

Keep dependencies updated.

Validate document inputs and handle malformed files safely.
Avoid placing extracted document content in unnecessary logs.
Review browser storage and caching behavior.

Test export and download paths, not just viewing.
The threat model should determine which controls are required.

Security must follow the document through every operation. Opening a PDF is only the beginning. **

Users may search, highlight, annotate, redact, export, print, or download it.

Each operation creates different questions.

For example, drawing a black rectangle over sensitive text does not necessarily remove that text from the underlying PDF. A safe redaction process must address the actual document content, not just its appearance.

Similarly, a viewer that processes the original file locally could still upload an exported document if its integration sends the result to a server.

Security reviews should follow the document from input to final output.

Make the architecture testable.

A useful test plan includes several independent checks.

Network inspection: Monitor requests during all document operations.
Output inspection: Extract text from exported PDFs and check whether supposedly removed content remains.

Dependency review: Examine the packages and external resources used by the application.

Permission testing: Verify that disabled operations cannot be accessed through alternate UI paths or public APIs.

Failure testing: Try malformed documents, interrupted operations, and unsuccessful exports.

No single check proves that a viewer is secure. Together, they provide stronger evidence than a marketing claim.

Exploring a client-side PDF viewer

We have been developing TeamSync PDF Viewer, an open-source React PDF viewer SDK designed around client-side document processing, with capabilities including search, annotations, and redaction.

*Repository: https://github.com/angelbot-ai/TeamSync-PDF-Viewer
*

If you are evaluating browser-based document processing, the source code gives you a starting point for examining the implementation rather than relying only on a feature list.

Review the architecture against your own threat model before using it with sensitive documents. No viewer should be treated as automatically secure simply because it runs in a browser.

What is your minimum security checklist?

If you were evaluating a PDF viewer for a production application, which would you investigate first: network traffic, third-party dependencies, redaction correctness, or exported-file handling?

Share your approach in the comments. If this project is relevant to your work, try it and consider starring the repository if you find it useful.

Your PDF Viewer Runs in the Browser. Does That Actually Make It Secure?

AngelBot AI — Mon, 26 Oct 2026 08:52:00 +0000

Moving document processing into the browser can reduce server-side exposure.

But there is a difference between processing a document locally and building a genuinely secure document workflow.

That distinction matters when your application handles contracts, financial records, employee documents, legal evidence, or other sensitive information.

Let's look at what client-side PDF processing changes, what it does not change, and what developers should verify before calling a document viewer secure.

What client-side processing actually means

In a traditional architecture, a user uploads a PDF to a server, the server processes it, and the application returns a result.
Depending on the system, that process might involve temporary files, document conversion services, storage systems, logging, or third-party APIs.

With a client-side architecture, some or all document processing happens inside the user's browser.

That can eliminate the need to upload a document to your application server for those particular operations.

However, client-side processing is an architectural choice, not a complete security guarantee.

The application can still introduce risks through its own code, dependencies, permissions, browser environment, and data flows.

Find out where the document actually travels.

Do not rely on a product description that says processing happens locally.
Inspect the implementation.

Ask questions such as:

Is the original PDF uploaded to an application server?
Does the application send document content to an external API?
Are extracted text, annotations, or search queries transmitted anywhere?
Are document contents included in error reports or analytics events?
Does the application use remote conversion or OCR services?
Are temporary copies written to storage?

The answers depend on the actual implementation and configuration.

Browser developer tools can help you inspect network requests during document loading, search, annotation, and export. For a serious security review, combine that inspection with source-code review and testing across all relevant workflows.

A quiet network tab during initial loading is not proof that no data leaves the browser later.

Remember that the browser is not a trusted vault

Local processing changes where computation happens, but it does not make the user's environment invulnerable.

For sensitive document applications:

Minimise unnecessary third-party scripts.
Apply an appropriate Content Security Policy.
Keep dependencies updated.
Validate document inputs and handle malformed files safely.
Avoid placing extracted document content in unnecessary logs.
Review browser storage and caching behaviour.
Test export and download paths, not just viewing.

The threat model should determine which controls are required.

Security must follow the document through every operation

Opening a PDF is only the beginning.

Users may search, highlight, annotate, redact, export, print, or download it.

Each operation creates different questions.

Similarly, a viewer that processes the original file locally could still upload an exported document if its integration sends the result to a server.

Security reviews should follow the document from input to final output.

Make the architecture testable

A useful test plan includes several independent checks.

Network inspection: Monitor requests during all document operations.

Output inspection: Extract text from exported PDFs and check whether supposedly removed content remains.

Dependency review: Examine the packages and external resources used by the application.

Permission testing: Verify that disabled operations cannot be accessed through alternate UI paths or public APIs.

Failure testing: Try malformed documents, interrupted operations, and unsuccessful exports.

No single check proves that a viewer is secure. Together, they provide stronger evidence than a marketing claim.

Exploring a client-side PDF viewer

We have been developing TeamSync PDF Viewer, an open-source React PDF viewer SDK designed around client-side document processing, with capabilities including search, annotations, and redaction.

Repository: https://github.com/angelbot-ai/TeamSync-PDF-Viewer

If you are evaluating browser-based document processing, the source code gives you a starting point for examining the implementation rather than relying only on a feature list.

Review the architecture against your own threat model before using it with sensitive documents. No viewer should be treated as automatically secure simply because it runs in a browser.

What is your minimum security checklist?

If you were evaluating a PDF viewer for a production application, which would you investigate first: network traffic, third-party dependencies, redaction correctness, or exported-file handling?

Share your approach in the comments. If this project is relevant to your work, try it and consider starring the repository if you find it useful.

PDF rendering and performance

AngelBot AI — Thu, 22 Oct 2026 05:57:23 +0000

Your PDF Viewer Works Until Someone Opens a 300-Page File

A PDF viewer can look perfectly fine during development.

You open a five-page document. The pages render correctly. Zoom works. Scrolling feels smooth.

Then someone uploads a 300-page technical manual, a large contract, or a scanned report with high-resolution images. Suddenly, the experience changes.

The browser becomes sluggish. Pages take too long to appear. Zooming feels delayed. Sometimes the interface becomes almost unusable.

The problem is not always the PDF itself. Sometimes, it is how the viewer handles rendering, memory, and the browser viewport.

Why large PDFs are different

A PDF is not simply a collection of images waiting to be displayed.

A document may contain text instructions, vector graphics, embedded fonts, images, annotations, and other objects. Rendering those elements requires work, and the cost varies significantly from one page to another.

A 300-page text document may behave very differently from a 30-page architectural drawing containing enormous images.

*This is why page count alone is not a reliable measure of rendering cost. *

Do not render every page at full resolution immediately

One common mistake is trying to render the entire document as soon as it loads.

If each page creates a canvas, that can quickly increase memory consumption. High-resolution canvases are particularly expensive.

A rough estimate for an RGBA canvas is:
width × height × 4 bytes

For example, a canvas measuring 1,500 × 2,000 pixels requires approximately 11.4 MiB of pixel memory before accounting for additional browser and rendering overhead.

Multiply that by dozens or hundreds of pages, and the cost becomes significant.

A better approach: Render visible pages first, then render nearby pages as the user scrolls. Release or reuse resources when appropriate.
Virtualisation and lazy rendering can help, but they should be designed around the viewer's actual interaction model.

Treat Zoom as a rendering problem

Zooming is more complicated than changing the CSS width of a canvas.
If the display size changes but the underlying rendering resolution does not, text and graphics may become blurry.

If every tiny zoom movement triggers an expensive rendering operation, the interface can feel slow.

A practical strategy is to separate the immediate visual response from the more expensive rendering work:

Update the viewport responsively.

Avoid triggering a new render for every intermediate input event.

Cancel obsolete rendering tasks where the rendering library supports it.

Render at the appropriate resolution after the zoom interaction settles.

The goal is to keep the interface responsive without sacrificing visual quality.

Keep the layers aligned.

A modern PDF viewer often needs more than a canvas.
It may also have a text layer for selection and search, an annotation layer for interactive elements, and controls for navigation.

These layers must agree on page dimensions, scale, rotation, and position.
If they do not, users may see text that is difficult to select, highlights that miss their targets, or annotations that drift after zooming.

Whenever the viewport changes, check that every interactive layer uses consistent coordinate transformations.

Measure the right things

Instead of testing only whether a document opens, measure the following:
Time until the first page becomes visible.

Time required to render a typical page. Responsiveness during rapid zooming and scrolling. Memory usage with large documents. Behaviour when users jump directly to a distant page. Recovery after switching between documents.

Test with different document types, not just different page counts.

A large scanned document, a vector-heavy engineering drawing, and a text-heavy report can expose very different problems.

Try it in a real React application

If you are building a document-heavy application, you do not necessarily need to build the entire viewing interface from scratch.

We have been working on TeamSync PDF Viewer, an open-source PDF viewer SDK for React applications, with document rendering, search, annotations, and other document interaction features.

GitHub repository: https://github.com/angelbot-ai/TeamSync-PDF-Viewer

You can inspect the implementation, try the project, and explore the integration options before deciding whether it fits your application.
One question for other developers

What becomes your biggest bottleneck when a PDF viewer handles large documents: canvas memory, rendering time, text-layer alignment, or zoom responsiveness?

I would be interested in hearing what you have encountered in production.

If the project looks useful for your work, consider giving the repository a star. If you try it, feedback and reproducible issues are especially valuable to an open-source project.

A Black Rectangle Is Not a Redaction was published.

AngelBot AI — Thu, 15 Oct 2026 04:24:50 +0000

A Black Rectangle Is Not a Redaction

Every year the same story pops up in the news. A law firm, a government agency or a company publishes a document with sections blacked out. Someone opens the file, highlights the blacked-out sections, hits copy, and pastes the secret text right out.

It is embarrassing and it keeps happening. The reason is that most tools make it easy to draw a black box and difficult to actually remove the information underneath.

Why does the text survive?

A PDF is closer to a set of drawing instructions than to a "document" in the everyday sense.

A line of text in a PDF looks roughly like this (simplified):

BT
/F1 12 Tf
72,700 TD
(Account Number: 4839 2201 5567) Tj
ET
BT begins a text object, Tf picks a font, Td positions it, Tj draws the string, and ET ends the object.
Both sets of instructions live in the same file. The renderer draws the text, then draws an opaque rectangle on top. Visually, the account number is gone. Structurally, nothing was removed.

That means every mechanism that reads the PDF instead of just looking at it will still find the string:

Text selection and copy
Search in the viewer and at the OS level.
pdftotext and other extraction libraries
Search indexing if the file is uploaded anywhere
Accessibility tools reading the text layer
The rectangle only defeats human eyes. It defeats nothing else.

And this isn't a bug. It's the default behavior of the most obvious interaction in many UIs. If your annotation tool has a filled-rectangle shape, a user can create a document that looks redacted but isn't in about four seconds, with no warning.
Now imagine you open that file and draw a black box over the account number. In most tools, you haven't deleted the text. You've just added more instructions: "draw a filled rectangle here."

BT
/F1 12 Tf
72 700 Td
(Account Number: 4839 2201 5567) Tj
ET
q
0 0 0 rg
70 695 180 18 re
f
Q

Both sets of instructions live in the same file. The renderer draws the text, then draws an opaque rectangle on top. Visually, the account number is gone. Structurally, nothing was removed.

That means every mechanism that reads the PDF instead of just looking at it will still find the string:

Text selection and copy
Search in the viewer and at the OS level
pdftotext and other extraction libraries
Search indexing if the file is uploaded anywhere
Accessibility tools reading the text layer
The rectangle only defeats human eyes. It defeats nothing else.

And this isn't a bug. It's the default behaviour of the most obvious interaction in many UIs. If your annotation tool has a filled-rectangle shape, a user can create a document that looks redacted but isn't in about four seconds, with no warning.

The three things that have to be true

Once you stop thinking of redaction as "drawing a black box" it becomes clearer what a safe redaction actually needs to do. A tool can get one or two of these right and still be unsafe, because all three have to work together.

The visual content has to be destroyed, not covered. On export, the affected region has to be rewritten so that the original marks are no longer present in the output — not present-but-hidden. We do this by rasterising and baking the redacted region into the exported PDF, so the sensitive content becomes part of a flattened result rather than sitting underneath something opaque.

Clean up the text layer too. Even with the visuals handled, a PDF usually carries a separate text layer used for search, selection and accessibility. If the sensitive string is still in that layer, nothing has been protected. So a proper redaction has to do two things: remove the text from the visible page, and remove it from the selectable and searchable text layer as well. Only then do copy-paste, search and extraction stop reaching it.

Keep "marked" and "applied" redactions separate. This is where a lot of tools go wrong, and it is the more subtle failure of the three. There are two states:

Marked — the user has drawn boxes over sensitive areas, but nothing has been permanently removed yet. This is editor state, and the user should be able to move, edit or delete these marks.
Applied — the document has been transformed so the original content is actually gone. This is a deliberate, destructive action.
The dangerous bug happens when these two states get blurred. A user sees black boxes, assumes the document is safe, and exports it — but the export path never ran the apply step. The file looks correct and is not.

The coordinate problem

There is a detail underneath all of this that took us longer than expected.

To remove text from the visible layer you need to know which extracted characters correspond to the region the user marked. That is not free. Text extraction gives you strings and geometry; a marked redaction gives you a rectangle. Mapping between them means maintaining a correspondence between extracted characters and their positions on the page.

We render and extract with PDF.js, and we ended up with a shared text builder and a single bounds-for-range function used by both document search and by regex-driven redaction. Which sounds like ordinary refactoring, and it was — but the reason it mattered is that search and redaction were answering the same question, where on the page is this text, and had drifted into two answers.

Two answers to that question are a correctness bug waiting to happen. If search can find a string that redaction cannot locate, you have a tool that will tell a user the sensitive text exists and then fail to remove it.

The regex path is worth mentioning because it addresses a real gap in manual redaction. A person marking boxes by eye will redact the account number they noticed. They will miss the second occurrence on page 9. Pattern-driven redaction over the extracted text catches what visual inspection misses, and it only works if the coordinate mapping is shared and trustworthy.

What this does not solve

I would rather say this plainly than have someone discover it.

The original file is untouched. All of this happens on export. If a user redacts a document and then sends the original instead of the exported copy, nothing has been protected. The workflow has to make the exported file the obvious thing to hand over.

Rasterising has costs. The redacted region stops being vector text. That means it is no longer selectable or machine-readable in that area, which is usually the point, but it also affects file size and accessibility. It is a deliberate trade, not a free win.

Visual redaction is not full document cleaning. Metadata, XMP, embedded attachments, form field values, annotations elsewhere in the file, and revision history are separate surfaces. Blacking out a name on page 3 does nothing about that name sitting in the document title. If you are redacting for a legal or compliance obligation, the page content is one item on a longer checklist.

Scanned documents are a different problem. If the page is an image with no text layer, there is no extraction to work with and no strings to pattern-match. Rasterising the region works; everything that depends on the text layer does not apply.

What I would check tonight
If you ship anything that lets users redact a PDF, three checks, in order:

Export a redacted file and run pdftotext on it. If the redacted string comes back, you are drawing rectangles. This takes thirty seconds and it is the only test that matters.

Try to reach an export with pending, unapplied redactions. If you can, and nothing warns you, that is your most dangerous path.

Search your exported document for the redacted string inside your own viewer. If your search index and your redaction logic disagree about where text is, this is where it shows up.

The distinction worth carrying away is the one that took us too long to state clearly: redaction is a document transformation, not an annotation. The black rectangle is a status indicator. The security property comes from the original information no longer being reachable through the normal mechanisms — extraction, search, copy — and those mechanisms do not care what the page looks like.

We work on TeamSync PDF Viewer, an open-source client-side PDF viewer for React.

If you have hit the copy-paste-recovers-the-text problem from the other side — as the person who found it in someone else's document — I would be interested to know which tool produced it. I suspect the list is short and repetitive.

Our stylesheet was quietly restyling our users' apps. It took us weeks to notice.

AngelBot AI — Mon, 12 Oct 2026 06:56:26 +0000

Our stylesheet was quietly restyling our users' apps. It took us weeks to notice.

A user opened an issue that made no sense to us.

Their sidebar had gone wrong. Wrong width, white background where it should have been dark, and it had shifted a few pixels down the page. Nothing to do with PDFs. They had not opened a PDF. They had not even clicked the button that opens one.

They had installed our viewer package, imported it, and their own sidebar broke.

We spent longer than I want to admit looking in the wrong place.

The part that did not add up

The thing that kept throwing us off was the timing. The breakage happened before any document was loaded. Our renderer had not run. No canvas existed. As far as we were concerned the library had not done anything yet.

That turned out to be the clue, not the mystery. Because something had run. The import had pulled in our stylesheet.

What was actually in our CSS

Our package ships dist/style.css. We had assumed that file contained our rules. It contained our rules plus pdfjs-dist/web/pdf_viewer.css, which is around 900 selectors written for pdf.js's own standalone viewer application.

That file was never meant to be a dependency of somebody else's design system. It was written for a page where pdf.js owns the whole document, so its class names are as plain as you would expect in that situation:

.sidebar
.dialog
.toggle-button
.closeButton
.messageBar

Read that list again as a library author. Those are not namespaced names. Those are the names half the web already uses.

We had scoped our own rules under .tspdf-root. We were reasonably careful about that. The pdf.js rules went out completely unscoped, because we had never actually looked at what our bundled CSS contained after the build ran.

Why it always won

Here is the bit worth remembering even if you never touch a PDF library.

Our stylesheet is injected at runtime, when the module is imported. That puts it late in document order. And in the cascade, when two rules have the same specificity, the later one wins.

So the host application had a perfectly sensible .sidebar rule of its own, written first, loaded normally. Ours arrived afterwards and quietly took the tie. Same specificity, later position, done. Their sidebar picked up position: relative, an inset-block-start they never asked for, a width meant for a PDF thumbnail rail, and a white background.

No error. No warning. No console output. Just a layout that was subtly wrong and a developer with no reason to suspect the PDF library, because they had not used it yet.

Silent conflicts are the worst kind. A crash tells you where to look.

The fix that did not work

The first idea was the obvious one: prefix every selector in the bundled file with.tspdf-root and move on.

It broke the viewer.

Two reasons, and both are easy to walk into.

Nesting. If you run a naive prefix pass over CSS that still has nesting in it, you prefix the outer selector and leave the inner ones alone, or you catch some of them twice. What comes out the other side is a file where some rules match nothing at all. Everything looks fine until you open the viewer and half the toolbar has no styling.

:root, html and body. You cannot prefix these. .tspdf-root :root matches nothing, ever. And :root was not decorative — it held the custom properties that the rest of the pdf.js rules read through var(). Prefix it and every one of those lookups fails, so you get a viewer with no colours and no spacing, and a stylesheet that technically contains every value it needs.

What we actually did

Two changes.

Scope after nesting is flattened, not before. The scoping pass now runs at build time, once the nesting is already resolved, so every selector in the output is a real flat selector and gets prefixed exactly once.

*Re-target :root, html and body instead of prefixing them. *
They become .tspdf-root. The custom properties then live on our root element rather than the document root, and every descendant that reads them still resolves correctly, because those descendants are
inside .tspdf-root anyway.

That was the whole fix. Not complicated. It just needed us to stop thinking of the scoping problem as a string replacement.

The part I would actually recommend copying

We added a check to npm run verify:package that fails the build in two cases:

Any selector in the shipped CSS is unscoped.
Any selector is prefixed more than once.

The second one matters more than it looks. A double-prefixed selector matches nothing, so it does not throw and it does not warn. It just silently stops applying, and you find out when a user tells you the toolbar looks broken. Catching it at build time turns an invisible bug into a failed CI run.

If you ship CSS in an npm package, that check costs an afternoon, and it will pay for itself.

If you ship a library with styles
Three things I would check tonight, in order:

Open your built CSS file. Not your source. The file that actually goes in the tarball. Read the selectors. If any of them could plausibly appear in somebody else's application, that is a bug waiting to be filed against you by someone who will have no idea it was your fault.

Check every transitive stylesheet. Ours came in through a dependency we were glad to have. We inherited its CSS along with its rendering, and we never inspected the result. Anything you bundle, you ship.

*Assume you win every tie. * Runtime injection means late in document order. Late means you take every equal-specificity conflict against your own users' code. That is not a position you want to be in by accident.

None of this is difficult. It is just not on the checklist, and it should be.

We hit this while working on TeamSync PDF Viewer, an open-source client-side PDF viewer for React. The fix shipped in v1.2.1 if you want to read the changelog entry.

If you have run into the same thing from a different library, I would be curious which one. I suspect this is far more common than the number of issues filed about it.