DEV Community: Sora Labs

A blob URL needs an owner, not just a cleanup call

Sora Labs — Sun, 04 Oct 2026 11:45:18 +0000

Disclosure: This article was generated with AI from a source-code review and browser API documentation. Its API claims were checked against the linked MDN references, and the example's lifecycle behavior was tested in a mocked DOM. It is not a report of measured production results or real-browser compatibility testing.

A file-preview widget can look complete when an image appears and its download link works. There is another question worth answering: what ends the lifetime of the URL connecting those elements to the file?

URL.createObjectURL(blob) creates a browser-managed URL referring to a Blob or File. It does not create a hosted download. Treat that URL as a resource the widget owns, rather than an arbitrary string to leave behind. MDN: createObjectURL

Define when the UI stops needing it

For a preview with a download link, reasonable boundaries are:

The user replaces the selected file.
The user resets the widget.
The component is disposed by the application.

The image finishing its initial load is not necessarily that boundary: the user might still need the URL for a download or an image interaction. MDN's image example cautions against revoking the URL too early. MDN: using files

Give the preview and download one shared owner

Here is a small synchronous example. It previews a selected image and offers the original file for download; it performs no conversion or compression.

<input id="file-input" type="file" accept="image/*">
<img id="preview" alt="Selected image preview" hidden>
<a id="download" hidden>Download original</a>
<button id="reset" type="button">Reset</button>

const fileInput = document.querySelector('#file-input');
const preview = document.querySelector('#preview');
const download = document.querySelector('#download');
const resetButton = document.querySelector('#reset');
let ownedUrl = null;

function clearPreview() {
  preview.hidden = true;
  download.hidden = true;
  preview.removeAttribute('src');
  download.removeAttribute('href');
  download.removeAttribute('download');

  if (ownedUrl !== null) {
    URL.revokeObjectURL(ownedUrl);
    ownedUrl = null;
  }
}

fileInput.addEventListener('change', () => {
  clearPreview();
  const selectedFile = fileInput.files?.[0];
  if (!selectedFile) return;

  ownedUrl = URL.createObjectURL(selectedFile);
  preview.src = ownedUrl;
  download.href = ownedUrl;
  download.download = selectedFile.name;
  preview.hidden = false;
  download.hidden = false;
});

resetButton.addEventListener('click', () => {
  clearPreview();
  fileInput.value = '';
});

Both elements share a URL, so cleanup waits until neither should use it. Resetting twice is safe because the owner is cleared after revocation. An application that removes this component should also remove its event listeners and call clearPreview() during disposal.

accept="image/*" is a picker hint, not file validation. A complete widget should handle unsupported or corrupt images, errors and accessibility requirements. This deliberately small example does not solve those concerns.

Do not mistake revocation for secure deletion

Revocation releases the object URL's association with its backing object. It does not prove that all file-related memory has immediately disappeared or that bytes have been securely erased. Other references or decoded image data can have separate lifetimes. MDN: revokeObjectURL

If processing is asynchronous, resource cleanup is also not cancellation. An older task may finish after a reset. Check that it is still the current task before attaching a newly created result URL. This example avoids that separate problem by doing no asynchronous processing.

Check the lifecycle, not just the first render

Try selecting image A, replacing it with image B, resetting twice, selecting again, and downloading while the preview remains visible. During component teardown, verify that its URL and listeners are released. Instrument create/revoke calls in a test adapter if you need deterministic accounting; do not infer success merely from an immediate drop in reported browser memory.

The useful design question is simple: which part of the interface owns this resource, and which user action ends that ownership?

Why Browser-Based PDF Tools Can Be More Private Than Cloud PDF Converters

Sora Labs — Tue, 01 Sep 2026 16:33:19 +0000

PDF tools are everywhere.

Compress a PDF. Merge two files. Convert an image. Remove metadata. Sign a document.

Most of us use these tools without thinking much about what happens after clicking Upload.

But there is an important architectural difference between two tools that may look identical from the outside:

One uploads your document to a remote server.

The other processes it directly inside your browser.

That difference matters.

The traditional model: upload, process, download

A typical online document tool works roughly like this:

You select a file.
Your browser uploads it to the provider's server.
The server processes the document.
You download the result.
The provider hopefully deletes the uploaded copy.

This architecture isn't automatically unsafe. Reputable companies can use encryption, access controls, short retention periods and strong infrastructure.

But it introduces something that doesn't need to exist for many document-processing tasks:

your file leaves your device.

That creates additional questions.

How long is the file stored?

Which server processes it?

Who can access the infrastructure?

Are backups created?

Are uploaded documents logged?

What happens if the service is compromised?

For ordinary photos, these questions might not matter much.

For tax documents, contracts, identification documents, invoices, medical files or internal company PDFs, they can matter considerably.

Modern browsers are surprisingly capable

Browsers are no longer simple document viewers.

Modern JavaScript, WebAssembly, Web Workers and browser APIs allow surprisingly complex operations to happen locally.

A web application can potentially:

merge PDFs
split PDFs
rotate pages
manipulate images
resize images
compress certain files
remove metadata
generate documents
perform OCR
process media

without uploading the original document to a remote server.

The website still needs to download application code, of course.

But once that code is running, the actual user file can remain on the user's machine.

The architecture becomes:

File → Browser → Processing → Result

instead of:

File → Internet → Server → Processing → Internet → Result

That is a meaningful reduction in exposure.

Local processing isn't automatically private

There is an important caveat.

A website claiming to run "in your browser" doesn't automatically mean everything stays local.

The application could still:

upload files through another API
send extracted text to analytics services
transmit metadata
use server processing for specific operations
make third-party network requests

So the privacy claim should be technically verifiable.

Developers building local-first tools should make the architecture explicit and minimize unnecessary network access.

Browser developer tools can also help technically inclined users inspect network traffic while a document is being processed.

Why I started building around this model

While working with online document utilities, I kept coming back to a simple question:

Why upload a private file when the user's own computer can perform the operation?

That became one of the principles behind SoraFiles, a privacy-first collection of PDF, image and document tools I'm building around browser-local processing wherever practical.

The goal isn't merely to put traditional server-side utilities into another interface.

The more interesting challenge is determining how much document processing can realistically be moved to the client while keeping the experience fast and usable.

That introduces engineering tradeoffs of its own.

Local processing has disadvantages too

Client-side processing is not a magical solution.

Device performance varies

A powerful desktop computer and an inexpensive smartphone have dramatically different processing capabilities.

Heavy operations can consume:

CPU
RAM
battery
browser storage

Developers therefore need sensible file limits and graceful failure states.

Large engines increase download size

Some advanced document-processing libraries and machine-learning models can be very large.

Downloading hundreds of megabytes just to perform a simple operation would create a terrible user experience.

Lazy loading and caching can help, but there is always a tradeoff.

Some operations genuinely belong on servers

Certain jobs may require infrastructure that isn't realistic inside a browser.

Large-scale OCR, complex document reconstruction, very large files and computationally expensive AI workflows are examples.

The correct architectural goal therefore shouldn't be:

"Servers are bad."

It should be:

"Don't send user data to a server unless the operation actually requires it."

Local-first can improve performance too

Privacy isn't the only benefit.

Removing the upload/download cycle can make some tools noticeably faster.

Consider a 100 MB document.

A server-based application may need to:

upload 100 MB
process it
download the result

On a slow connection, file transfer can take considerably longer than the actual computation.

With local processing, the file is already on the device.

This also makes some tools more resilient on unreliable internet connections.

It changes the economics of running the service

There is another advantage developers don't always discuss.

Server-side document processing costs money.

Large files consume:

bandwidth
temporary storage
compute
memory
queue capacity

As usage grows, infrastructure expenses grow with it.

When users perform appropriate workloads on their own devices, much of that variable infrastructure cost disappears.

That can make it easier to provide useful tools for free without aggressively monetizing users.

Privacy can be an architectural decision

Privacy policies are useful.

Encryption is important.

Retention policies matter.

But one of the strongest privacy protections is simply not collecting the data in the first place.

If an operation can safely happen on the user's device, there is often little reason for the application developer to receive the original file at all.

That's why I think we'll see more web applications adopt local-first or hybrid architectures over the next few years.

The browser has quietly become a capable application runtime.

We should take advantage of it.

I'm experimenting with this approach while building SoraFiles, and I'd be interested to hear from other developers working with WebAssembly, local-first applications or browser-based document processing.

What workloads have you successfully moved from the server to the browser?

7 Engineering Lessons From Building File Processing Directly in the Browser

Sora Labs — Tue, 25 Aug 2026 17:31:57 +0000

I've been building SoraFiles, a privacy-first web app for working with PDFs and images directly in the browser.

The interesting part has not been creating another upload form.

It has been removing the upload step entirely for supported workflows.

The basic architecture is:

User file
-> Browser File API
-> Local JavaScript / WebAssembly processing
-> Result
-> Download

Instead of:

Browser
-> Upload
-> Processing server
-> Temporary storage
-> Download

That sounds simple until you try to make it reliable on phones, Safari, large PDFs, corrupt files, repeated user actions, and limited browser memory.

Here are seven engineering lessons that have mattered most.

============================================================

1. TREAT EVERY PROCESSING OPERATION AS A JOB

The simplest implementation is also the one most likely to create stale-state bugs.

A user clicks Process.

The job starts.

Before it finishes, they remove the file and select another one.

If the first operation is still allowed to update the interface, the old result can suddenly appear inside the new workflow.

That is confusing and dangerous.

A better model is to treat every processing operation as a job with:

a unique identity
a state
cancellation
ownership of its resources

The lifecycle can be thought of as:

Idle
-> Ready
-> Processing
-> Success / Error / Cancelled

Before any asynchronous task updates the UI, the application should verify that it still belongs to the current active job.

That one idea prevents a surprising number of bugs.

============================================================

2. WEB WORKERS HELP, BUT OWNERSHIP STILL MATTERS

PDF rendering, OCR, compression, and image conversion can become expensive quickly.

Moving heavy work into Web Workers helps keep the interface responsive.

But a Worker does not magically solve memory problems.

Large buffers may still need to move between the main thread and the Worker.

So the important questions become:

Who owns this buffer?
Was it copied or transferred?
Can the main thread still use it?
What happens when the user cancels?
Who cleans it up?
Can the Worker be terminated safely?

Local processing becomes much easier to reason about when data ownership is explicit.

============================================================

3. CLEANUP IS PART OF THE ALGORITHM

A browser-local file application can create a lot of temporary resources:

canvases
image bitmaps
PDF rendering tasks
object URLs
Blobs
ArrayBuffers
workers
event listeners
temporary decoded documents

If you create them and never clean them up, the browser may keep enough memory alive to make the app unstable on mobile.

I now think of cleanup as part of the actual processing pipeline:

Validate
-> Decode
-> Process
-> Encode
-> Expose result
-> Cleanup

Not:

Process
-> Hope garbage collection eventually fixes everything

This matters especially on iPhones and lower-memory devices.

============================================================

4. A 20 MB FILE DOES NOT MEAN 20 MB OF MEMORY

Compressed file size and in-memory size are very different things.

A 20 MB PDF may temporarily involve:

the original ArrayBuffer
decoded page data
several canvases
preview images
intermediate output
the final result Blob

Images can expand dramatically when decoded into raw pixels.

So large-file support is not just about removing an arbitrary upload limit.

It requires:

bounded concurrency
sequential processing where possible
avoiding unnecessary buffer copies
releasing resources quickly
lower-resolution previews
cancellation
capability-aware limits

Desktop browsers can hide inefficient architecture.

Phones expose it.

============================================================

5. PREVIEW RENDERING CAN BECOME A PERFORMANCE BUG

A preview looks like a UI problem.

It is also a memory problem.

Suppose a PDF page is displayed inside a 320-pixel-wide card.

If you render that page internally at several thousand pixels and simply shrink it with CSS, the preview may look correct while still consuming far more memory than necessary.

A better approach is:

Determine the actual visible preview size.
Account for device pixel ratio.
Render close to the resolution the UI genuinely needs.

The browser is both your renderer and your processing machine.

Waste resources on the preview and you leave fewer resources for the actual file operation.

============================================================

6. DEFINE WHAT ANALYTICS MUST NEVER RECEIVE

Analytics usually starts with:

"What should we track?"

For software handling private documents, I think the first question should be:

"What should never reach analytics?"

For SoraFiles, file-derived information should remain outside the analytics layer.

That includes things such as:

filenames
document text
OCR output
metadata values
passwords
signatures
image pixels
generated file contents

You can still learn whether the product works.

For example:

Tool opened
-> Processing started
-> Processing succeeded

That tells you whether users can complete a workflow.

You usually do not need to know what was inside their document.

The rule I like is:

Analytics should answer "Did the workflow work?" without answering "What was inside the user's file?"

============================================================

7. HONEST LIMITATIONS BUILD MORE TRUST THAN PERFECT-SOUNDING CLAIMS

Some file operations are relatively straightforward.

Others are not.

Examples of difficult workflows include:

PDF to Word
Word to PDF
OCR
PDF repair
complex spreadsheets
unusual fonts
forms
embedded objects
complicated page layouts

Browser libraries are powerful, but they do not perfectly reproduce every edge case.

If a conversion may simplify a complex layout, tell the user before processing.

If transparency must be flattened, explain it.

If a very large file may exceed the browser's practical memory limit, say so.

Users can understand limitations.

What destroys trust is discovering them only after downloading the result.

============================================================

WHY LOCAL PROCESSING IS INTERESTING

Server-side processing still has real advantages:

predictable compute
larger memory pools
powerful native libraries
easier handling of huge files
consistent execution environments

Local processing has different advantages:

files can stay on the user's device
no upload wait
reduced server-side exposure
some workflows can continue offline
less processing infrastructure is required

So I do not think the right question is:

"Should everything run locally?"

A better question is:

"Does this operation genuinely require the user's file to leave their device?"

For many routine PDF and image operations, modern browsers increasingly make the answer:

No.

============================================================

OPEN SOURCE AND INSPECTABILITY

SoraFiles is open source under AGPL-3.0.

Open source does not automatically make software secure.

It does not replace:

testing
dependency review
secure implementation
privacy engineering
vulnerability management

But it makes architectural claims easier to inspect.

People can look at the code and see how the processing path works.

For privacy-focused software, that inspectability matters.

============================================================

CLOSING THOUGHT

Building file processing directly inside the browser changed the way I think about privacy engineering.

The strongest privacy improvement was not another paragraph in a privacy policy.

It was removing unnecessary data movement from the architecture.

Once that decision is made, privacy becomes an engineering problem:

memory management
workers
cancellation
state machines
browser compatibility
output validation
honest limitations
carefully separated analytics

That work is less visible than putting a privacy badge on a landing page.

It is also what makes the privacy claim meaningful.

If the user's device is already capable of doing the work, uploading their private file should not automatically be the default.

SoraFiles:
https://sorafiles.com

Source code:
https://github.com/Sora-Labs2026/SoraFiles

DISCLOSURE

Sora Labs develops SoraFiles.

SoraFiles is used here as the practical case study for the engineering lessons described in this article.