Documateo

Developers

Built to be inspected, not just trusted.

Notes on how Documateo actually works, for anyone evaluating it as infrastructure rather than just a tool — what runs where, how long data lives, and how to check our claims yourself.

Read the security detailAPI roadmap

Architecture

Two paths: one that never touches a server, one that expires

LOCAL PATH · 61 tools · no uploadYour browserfile stays in memoryWebAssembly + Web APIsCanvas · Web CryptoYour resulton your deviceSERVER PATH · 17 tools · expiresYour browseruploads the fileEdge APICloudflare WorkersQueuejob + short expiryContainer / AIdoes the workR2 storageresult held brieflyHourly sweep deletes uploads + results · nothing stays past the retention window

Execution tiers

Where each of the 97 tools runs

Execution tiers, tool counts and data lifetime
TierRuns onToolsExamplesData lifetime
BrowserYour device61Merge PDF, Split PDF, Compress PDF, Rotate PDFNever leaves your device
ContainerIsolated, short-lived containers13Protect PDF, Unlock PDF, Repair PDF, HTML to PDFAuto-deleted on a short timer
AIHosted AI models4PDF to Excel, OCR PDF, Remove Background, Upscale ImageAuto-deleted on a short timer
TemplateServer-side PDF render19GST Invoice, Rent Receipt, Quotation, Weekly PlannerContent never stored

Browser-tier tools use WebAssembly and native browser APIs — Canvas, Web Crypto, the File System Access API. For those, the privacy property is structural: there is no upload step in the code path.

Server-side jobs

The lifecycle of a job

  1. 01

    Queued

    The file is validated by its signature (not just its extension) and a job is created with a short expiry.

  2. 02

    Processing

    A container or model picks the job up. Progress is reported while it runs.

  3. 03

    Done or failed

    On success you download the result. If a job fails on our side, the credits it used are returned automatically.

  4. 04

    Swept

    An hourly job deletes anything past its expiry — uploads and results alike — so nothing outlives the retention window in our Privacy Policy.

Conversion and repair run in short-lived, network-isolated containers with a read-only filesystem and no state carried between jobs, so one person's upload never shares infrastructure with another's.

The stack

Small surface, boring parts

Website
Next.js, statically exported and served from Cloudflare's edge
API
Cloudflare Workers
Async jobs
Queues feeding containers (FFmpeg, LibreOffice, qpdf) and hosted AI models
File storage
Cloudflare R2, with a short expiry on every object and an hourly sweep
Payments
Razorpay — verified twice: a signed check at checkout, then Razorpay's signed webhook

Don't take our word for it

Verify a Local tool yourself

  1. 1Open your browser's developer tools and switch to the Network tab.
  2. 2Run any tool badged Local — try Merge PDF — on a file.
  3. 3Watch the request list. You'll see the page's own assets load, but no request carries your file out.
  4. 4Now run a tool badged Cloud. This time you'll see the upload request — that's exactly the difference the badge is telling you about.

For crawlers & agents

Machine-readable by design

Every page is statically rendered with structured data, and the catalogue is generated from the same registry that drives the site, so these indexes can't fall out of date.

Building something on top of this?

A programmatic API for every tool is in development for Business plans. Tell us what you'd build.

See the API roadmapGet in touch