The idea
Most online file tools follow the same pattern: upload your file, wait in a queue, download the result. That pattern is the product, and it has a consequence people do not think about until they upload something they should not have — the file passes through a machine belonging to a stranger, and so does everything in it.
A browser already has everything needed to do this work. It can decode images, parse documents, run compression algorithms and encode results. Furtu's premise is that if the processing happens locally, the upload step disappears, and with it the privacy problem, the queue, and the storage obligation.
What that looks like in practice
- Privacy claims are derived, not written. Each tool declares how it processes files, and the badge on the page is generated from that. A claim cannot drift away from the implementation without the page changing.
- Tools load when you open them. The PDF engine is not in the page until you open a PDF tool. A visitor who only ever formats JSON never downloads a PDF library.
- No account, ever. There is nothing to sign up for, so there is no profile to leak and no credential to phish.
- Limits are stated before you hit them. Each tool page lists its real constraints, including the ones that are inconvenient for us to admit.
The trade-off we accept
Some things genuinely cannot be done well in a browser. Password-protecting a PDF, OCR on a scanned document, and re-encoding the images inside a scanned file to make it much smaller all need more compute, a native library, or both. Where that is the case, Furtu says so on the tool page instead of shipping something that appears to work.
How it is built
Furtu is a single, coherent application rather than several tools in one website. Processing engines are separated from the interface so the same code can serve a web app, a future API or a mobile client without being rewritten.
Adding a tool is one file of metadata plus one file of processing code. Routing, search, the command palette, breadcrumbs, related-tool links, the sitemap and the page's structured data all follow from the registry, which is why the catalogue can grow without the architecture having to be revisited.
The design system is the original FURTU design, extended rather than replaced: an editorial serif for statements, a monospace face for technical annotation, one blue, and no gradients, glass or neon.
Open source
Furtu is built on permissively licensed libraries — pdf-lib, pdf.js, js-yaml, qrcode and fflate among them. Their copyright notices are preserved and their licences are listed in the third-party notices in the project repository.
Two projects that were evaluated as possible sources were not used, because neither carried a licence. Absent a licence, default copyright applies and the code is not reusable. That is recorded in the engineering report rather than quietly ignored.
Getting in touch
Tool requests, bug reports and disagreements about privacy claims are all welcome at hello@furtu.xyz. The changelog records what has actually changed, including the parts that are still unfinished.