UK Online Safety Act: Why Local Processing Is Exempt

Ofcom fined a file-sharing service £20,000 last month for not responding to its information requests. Two other services, 1Fichier and Gofile, were required to implement perceptual hash matching on their upload pipelines. New regulations took effect on January 8, 2026, and accredited technology guidance is coming this spring.

If you run a platform that receives file uploads, you now have a compliance obligation in the UK. You need to assess your risk, deploy scanning infrastructure, and answer regulator inquiries or face daily fines.

VaultTools has none of that surface. Here is why.

What the Online Safety Act Actually Requires

The UK Online Safety Act’s Illegal Content Codes of Practice target platforms that receive user files on their own infrastructure. The legal trigger is server-side receipt. A service is in scope if it stores files, makes them accessible to others, or facilitates sharing between users.

For high-risk file-sharing platforms, Ofcom recommends perceptual hash matching: a technique that generates cryptographic fingerprints of uploaded content and compares them against databases of known illegal material. Some platforms implemented it voluntarily. Others got told to. One refused to cooperate and got fined.

The compliance stack is real. You need:

• An illegal content risk assessment
• A scanning system that meets Ofcom’s technical standards
• A process for responding to statutory information requests within deadlines
• Ongoing monitoring and reporting

That is engineering time, legal review, third-party tooling costs, and a layer of infrastructure that touches every file a user uploads.

Why None of This Applies to VaultTools

VaultTools never receives files. When you drop a PDF into the merge tool, your browser loads the Wasm module from our CDN and runs it locally. The bytes of your file go from your disk into browser memory, through the Rust function compiled to WebAssembly, and back out as a download. Nothing leaves your machine.

Our servers serve static assets: HTML, CSS, JavaScript, and compiled .wasm binaries. They do not accept file uploads. There is no POST endpoint that receives a PDF. There is no S3 bucket storing your images. There is no processing queue handling your documents.

The Online Safety Act’s scanning obligation cannot attach to a server that never sees a file. Ofcom cannot compel us to scan uploads we do not receive. There is no server-side storage to audit because there is no server-side storage.

This is not a policy promise. It is not a claim in a privacy statement. It is an architectural fact that you can verify by opening your browser’s network tab while using any tool on the site. You will see requests for .wasm files and page assets. You will not see your file leaving your device.

The Architecture That Creates This Property

The core of every tool is a Rust function compiled to WebAssembly with wasm-pack. For example, the PDF merge tool calls into pdf-tools, one of five Rust crates in the codebase:

// crates/pdf-tools/src/merge.rs (simplified)
pub fn merge_pdfs(documents: &[Vec<u8>]) -> Result<Vec<u8>, String> {
    let mut output = Document::new();
    for bytes in documents {
        let doc = Document::load_mem(bytes)?;
        // merge pages into output...
    }
    Ok(output.save_to_bytes()?)
}

That function takes bytes in, returns bytes out. It has no network access. The Wasm sandbox enforces this at the runtime level: a Wasm module cannot open a socket, cannot write to the filesystem, cannot make HTTP requests unless the host explicitly provides those capabilities. We do not provide them.

The JavaScript on the page loads the Wasm module, passes your file’s bytes to the function, receives the result, and triggers a download. The round trip is entirely local.

Regulatory Pressure Now Favors Local-First

The Im.ge fine matters beyond the £20,000 number. It established that procedural non-compliance (simply not engaging with Ofcom) is a standalone offence. Platforms do not get to ignore the regulator. The daily penalty rate of £100 that follows is not threatening in isolation, but the escalating enforcement posture is.

Spring 2026 guidance will define which scanning technologies satisfy the Act. Once published, every file-upload platform serving UK users will have a defined technical baseline to meet or face enforcement. That baseline costs money to implement and maintain.

Meanwhile, the same regulatory trend is visible across jurisdictions. The EU’s Digital Services Act has overlapping obligations for large platforms. Sweden is debating surveillance requirements for messaging services. Several US states have enacted laws touching platform content moderation. The compliance surface for server-based file tools is only expanding.

Local-first processing does not just protect user privacy. It removes the operator from the compliance perimeter entirely. There is no upload pipeline to regulate. There is no content to scan. There is no data to retain or report. The architecture answers the regulation before the regulation is written.

What This Means in Practice

If you use VaultTools to process sensitive documents, the legal guarantee you actually want is not our word that we delete files after an hour. It is the structural impossibility of us ever having your files in the first place.

For lawyers processing client contracts, accountants handling tax documents, designers working with unreleased brand assets, or anyone running documents through a tool before sharing them, the question to ask is not “what is this platform’s retention policy?” It is “does this platform ever receive my file at all?”

For VaultTools, the answer is no. And that answer does not change regardless of what laws get passed, what regulators get involved, or what happens to the company.

Try it with your network tab open. Drop a file into any tool. Watch the requests. Your file never leaves.