Skip to content
English
The WorkbenchTools that upload nothing
A workshop by the ODERSA associationNothing leaves, nothing is kept, nothing reaches us.

How it works

What this site does is unremarkable engineering. What is rare is doing it without ever receiving your files, and saying precisely where the limits are.

The four building rules

The file does not leave the device

A browser can read a file, decode it, transform it and build a download. All of that happens there. There is no server receiving anything, because the site is a set of static files.

Zero network dependency

No library loaded from a third party, no remote font, no remote image, no embedded analytics. Everything the page loads comes from this domain, and nothing else is loaded.

The code can be read

Nothing is minified or obfuscated. A tool is one file, named after itself. That is what makes verification possible for someone who did not write the site.

Every tool states ITS formats and ITS limits

Never “all formats”. A format a browser cannot open does not become possible because someone wrote it on a home page.

The compatibility matrix

It is the result of a verification campaign run before the first tool was written, and it is dated. Browsers move: it gets re-checked at every review, it is not copied forward.

Compatibility checked on July 30, 2026

Image formats the browser can OPEN

This decides whether a tool can display your file and work on it. A format missing here is not “coming soon”: it is not there.

Chrome, EdgeFirefoxSafari (macOS, iOS)
JPEG (.jpg)yesyesyes
PNG (.png), including animatedyesyesyes
WebP (.webp)yesyesyes
Safari from version 14, on macOS Big Sur and later.
AVIF (.avif)yesyesyes
Chrome 85, Firefox 93, Safari 16.1.
GIF (.gif)yesyesyes
BMP (.bmp)yesyesyes
SVG (.svg)yesyesyes
ICO (.ico)yesyesyes
TIFF (.tif, .tiff)nonoyes
Safari is the ONLY browser that displays a TIFF. TIFF metadata, however, can be read everywhere: it lives in the file header, not in the image.
HEIC, HEIF (iPhone photos)nonoyes
Safari 17 and iOS 17 display them. Chrome, Firefox and Edge have never decoded them, because of codec patents. A software decoder weighs over ten megabytes: ruled out, and stated.
JPEG XL (.jxl)partlypartlyyes
Updated 2026-07-30. The least stable format of the lot: dropped from Chromium in 2022, then a decoder written in Rust returned in Chrome 145 in February 2026 and in Firefox 152 in June 2026, but DISABLED by default in both, behind a flag. Safari has displayed it by default since version 17. No browser can WRITE it. No tool on this site relies on it while the situation keeps moving.

Formats the browser can WRITE

This decides what a tool can convert your image into. The trap is silent: when a browser cannot write the requested format, it returns a PNG without warning. Our tools therefore check the type of the result instead of trusting it.

Chrome, EdgeFirefoxSafari (macOS, iOS)
Write a PNGyesyesyes
The only format the specification makes mandatory: it is also the universal fallback.
Write a JPEGyesyesyes
Write a WebPyesyesno
Chrome 50, Edge 79, Firefox 96. NO version of Safari, on Mac or iPhone, can write a WebP from a canvas. This is the most useful line in the whole matrix: a converter announcing “WebP” without saying this would lie to every other iPhone visitor.
Write an AVIFnonono
Line CORRECTED on 2026-07-30. The claim that Chrome can write an AVIF from a canvas from version 124 onwards is everywhere, copied from site to site, and we found NO first-hand source for it: no entry in the Chrome feature register, no release note, no dedicated compatibility page. Our tools therefore do not rely on it: they MEASURE at run time what the browser can write instead of assuming. If a browser exposes it tomorrow, the conversion tool will offer it without a line of code changing.

The browser capabilities the tools depend on

Chrome, EdgeFirefoxSafari (macOS, iOS)
Native cryptography (AES-GCM, password-derived key, SHA-256)yesyesyes
Available everywhere since 2017, but ONLY on a page served over HTTPS. This site is.
Native compression and decompression (gzip, deflate)yesyesyes
Available in every browser. Useful precision added 2026-07-30: the RAW deflate variant, the only one that serves to build a zip, arrived later than the rest (Chrome 103, Firefox 113, Safari 16.4). Zip code written between 2020 and 2022 could therefore fail on a Chrome that nonetheless claimed it could compress.
Off-screen image processing (in a separate thread)yesyesyes
Chrome 69, Firefox 105, Safari 16.4. This is what avoids freezing the page on a big file.
Barcode and QR reading by the operating systempartlynono
Hardened 2026-07-30, and it is stricter than what we had written. This is not a web standard: it leans on the operating system, so it exists ONLY on Chromium on macOS, ChromeOS and Android. It is ABSENT from Windows and Linux, which is to say from most desktop computers. Firefox never implemented it. Safari has an experimental version behind a flag since 17, and it has been BROKEN since iOS 18. A QR tool therefore cannot lean on it: it would have to carry its own reader.
Saving through the real “Save as” dialogyesnono
Chromium only; Firefox and Safari declined this interface. The fallback is the ordinary download, which works everywhere: that is what our tools use by default.
Hashing a file piece by piecenonono
The browser computes a SHA-256 fingerprint perfectly well, but ONLY on a whole file handed over at once: there is no function for feeding it progressively. That is what forces a weight limit on the fingerprint tool, and that limit carries this reason.
Encrypting a file as a stream, without loading it wholenonono
Same limit as for hashing: the browser's cipher works on one complete block, and the request for a streaming version has been open since 2016 with no answer. Splitting it yourself is possible, but each chunk must then be bound to its position, otherwise chunks can be removed or reordered without the seal noticing. Our encryption tool would rather state an honest weight limit than improvise a construction of that kind.
Modern key derivation (Argon2) in the browsernonono
Argon2 is today the first recommended choice for building a key from a password, and it exists in NO browser: it would take an embedded WebAssembly engine. Our encryption tool therefore uses PBKDF2 with SHA-256 and 600,000 rounds, the value published in 2026 by the reference in the field, and it SHOWS that on screen instead of implying better.
Writing an ICO icon file from a canvasnonono
No browser can write an ICO: the container has to be assembled by hand around PNG images. PNG inside an ICO has been accepted since Windows Vista and since Firefox 9; for Chrome, Edge and Safari we found only evidence of practice, not engineering sources. Worth knowing before promising an icon generator.
Computing a CRC-32, mandatory inside a zipnonono
The browser offers only cryptographic digests (SHA-1 and SHA-2). The CRC-32 that a zip file requires in each of its headers therefore has to be written by hand, in ordinary JavaScript. It takes about thirty lines, and it is the only brick missing to build a zip with no library.

Memory limits, the ones that actually crash a tab

They are written in no standard, which is why so many converters fail silently on phones. Every tool on this site states ITS limit, and refuses cleanly beyond it.

Chrome, EdgeFirefoxSafari (macOS, iOS)
Maximum canvas areayesyespartly
On iPhone and iPad, canvas area was long capped at 16.7 million pixels (4096 by 4096); iOS 18 raised it to 67.1 million. A 50-megapixel photo still exceeds the old limit: a tool that redraws the image must scale down first, or say no.
Total memory allocatable to canvasesyesyespartly
Safari on iOS caps the total canvas memory of a tab, around a few hundred megabytes depending on the device. Batch processing must therefore release each image before moving to the next, not only at the end.

PDF in a browser, and the real state of the libraries

The browser can do NOTHING with a PDF except display it. Any manipulation needs embedded code, and that is the only exception this site's doctrine allows. Here is what the check of 30 July 2026 established, and why the PDF corner is waiting on a decision rather than being half opened.

Chrome, EdgeFirefoxSafari (macOS, iOS)
Merging, splitting or editing a PDF with no library at allnonono
Nothing in a browser reads the structure of a PDF. Displaying is not reading: the built-in viewer lends none of its capabilities to a web page.
The manipulation library the project brief had planned forpartlypartlypartly
NEW FACT, AND IT CHANGES THE DECISION. This library is MIT licensed and knows how to do a great deal: merge, split, rotate, draw, fill forms, write metadata. But its last published version dates from NOVEMBER 2021, and its author has been unreachable since May 2024: the code the project intended to embed has not had a single fix in over four years. It can NEITHER encrypt NOR decrypt a PDF, exactly as its own documentation says.
Setting or removing a password on a PDFpartlypartlypartly
Technically POSSIBLE locally, which we did not think. A maintained continuation of that library, MIT licensed as well, implements PDF encryption up to AES-256 and can open a protected document. So this is no longer a technical impossibility: it has become a decision, the decision to embed a young continuation rather than the code named in the doctrine, and to make it this site's only dependency for years. That decision belongs to the association, not to the workshop.
Turning the pages of a PDF into imagespartlypartlypartly
Impossible with a manipulation library, which is not a rendering engine. It would take the engine behind Firefox's viewer, about 1.7 megabytes of code before compression, for a single tool: the weight of an entire site. To be reconsidered separately, never quietly.
Really making a PDF lighterpartlypartlypartly
A manipulation library can pack a document's internal objects together, which gains a little on a form-heavy PDF. It recompresses NEITHER the images NOR the fonts, which make up the vast majority of an ordinary PDF's weight. On a scanned document there is therefore almost nothing to gain, and a tool promising otherwise would be lying.
REALLY cleaning the metadata of a PDFpartlypartlypartly
Two traps that only reading the code reveals. First, the library rewrites a producer and a modification date of its own on every open, even when nobody asked. Second, it NEVER touches a PDF's modern metadata block, the one that can hold the same title and the same author as the rest: a cleanup stopping at the first would be false, and it would have to be proven by reading the produced file back.
Drawing a PDF page as an image (rasterising) with the embedded librarynonono
The PDF corner's library BUILDS PDFs, it does not paint their pages: its public interface exports no rendering symbol at all. Rasterising needs a second engine whose real weight, measured on its published files, is 1.72 MB minified (454,669 B for the interface, 1,262,398 B for the worker), around 502 KB compressed. So “PDF to images” is ruled out, and written down.
Encrypting a PDF with AES-256 in the browser, and opening oneyesyesyes
Possible with the embedded library, BUT at revision 5 only (Adobe's 2008 extension), not revision 6 of the PDF 2.0 standard. Revision 5 verifies the password with a SINGLE pass of SHA-256; revision 6 uses an iterated hash, and published benchmarks from attack tools show four to five orders of magnitude difference in trial speed. Revision 5 is the only one the PDF 2.0 standard deprecates. The algorithm depends on the file HEADER: measured, only the string “1.7ext3” triggers AES-256, otherwise you get RC4 or AES-128.
Opening an AES-256 revision 5 encrypted PDF in the browser's built-in readeryesyespartly
Verified in the SOURCE CODE of the engines: PDFium (Chrome, Edge) handles revision 5 right at its password check, and pdf.js (Firefox) carries a dedicated revision 5 class, distinct from the revision 6 one. Adobe Acrobat has opened it since version 9. For macOS and iOS Preview, and for Android readers, NO first-hand source was found: so the Safari column says “partly”, and the site claims nothing more.
Writing accented or non-Latin text into a PDF without embedding a font enginepartlypartlypartly
Without the font engine the library requires for any custom font (which we do not embed), only PDF's 14 standard fonts exist, in Windows-1252: about 218 Latin characters. A character outside that set does NOT raise an error in the shipped version: the code catches the exception and writes a question mark. So a tool that writes text has to validate the input and NAME what it cannot write.
Really preventing a PDF from being printed or copiednonono
The format lets you write those restrictions into the file, but they are only requests made to the reader: the content is decrypted the moment it opens, and a reader that ignores the request prints anyway. No tool, local or remote, can do better. So the site does not offer those checkboxes.

What we ruled out, and why

A site that is honest about its limits is more useful than a site that promises everything. Here is what we decided not to do, with the reason for each decision. These lines will only move if the reason moves.

  • Text recognition inside an image, and reading HEIC photos from iPhones: the engines required weigh between ten and fifteen megabytes. On a weak connection, downloading fifteen megabytes to read some text is a bad deal. To be reconsidered, never quietly.
  • Video, in any form: video conversion engines in a browser weigh around thirty megabytes. No.
  • AI background removal: it requires downloading a model, and a model is a heavy, opaque file. No.
  • Anything that REQUIRES the network by nature: shortening a link, expanding a short link, looking up a domain owner, showing a preview of a remote page. Those tools cannot be local, so they are not here. That is not a gap, it is the definition of the project.
  • Showing a map to place a photo: it would be the only outgoing request on the site, and it would carry the most sensitive information in the file. The coordinates are shown in plain text, and what you do with them is up to you.
  • TURNING A PDF INTO IMAGES: it would mean DRAWING the pages, and drawing a PDF is an entire trade (fonts, vectors, transparency, colour spaces). The library we embed can build a PDF, not paint a page of one. The only serious rendering engine on the web weighs, measured on the files it publishes, 1.72 MB minified for that single use. The other direction, images to PDF, is on the bench and works.
  • SIGNING A PDF: for the same reason, and it is the most frustrating one. Without a rendering engine we cannot SHOW the page; without showing it, we cannot let anyone place their signature where they want it. A signature dropped blind at fixed coordinates would be worse than useless. We would rather leave an empty place than offer a tool that damages a document.
  • READING A QR CODE: the function browsers offer relies on the operating system. So it only exists on part of Chromium, on macOS, ChromeOS and Android; it is absent from Windows and Linux, Firefox never implemented it, and Safari's experimental version has been broken since iOS 18. A tool relying on it would not work for the majority of desktop visitors. BUILDING a QR code, on the other hand, stays in the plan: it is feasible by hand, and the standard is free to use.
  • FORBIDDING PRINTING OR COPYING OF A PDF: the format allows it, and many tools show those checkboxes because they are reassuring. They are only requests made to the reader: the content is decrypted the moment it opens, and a reader that ignores the request prints anyway. Selling a lock that is a sticker would be exactly the kind of lie this site exists not to tell.
  • RECORDING FROM A MICROPHONE, the “dictaphone” half of place 34: the anatomy of a tool page on this site offers ONE input per tool, a file, a text or nothing, and every trust banner speaks about exactly that input. A microphone would be a fourth, with its own promise to write. Above all, the machine that checks this site before every release has no microphone: we could therefore not PROVE that a recording does not leave, and we do not publish a promise we cannot exercise. So place 34 is “trim a recording”, and your device keeps the job it already does very well.
  • THE GIANT PROJECTOR DISPLAY for the classroom timer: the largest character in our design system is the one in the counter blocks, and it was not drawn to be read from the back of a room. A giant display would be a new graphical component, the design is frozen, and something missing gets noted rather than invented in the middle of a tool. Fullscreen mode does exist and fills the screen, but it does not enlarge the digits, and the page says so twice. It is a request, it is noted, and it is not buried.
  • THE SPINNING WHEEL on the random draw, for the same reason: it is a component the design system does not have. And a wheel does not make a draw fairer, it stages it. What makes a draw fair is the random generator behind it and the absence of bias, and the tool shows both with their arithmetic: one chance in n, n factorial possible orders.
  • THE CLICKABLE CALENDAR in the date calculator: our design system has no date field drawn for it, and a browser's native date field would arrive with its own border and its own height, outside the design. So dates are typed in the international format, which has a real advantage: “03/04” means 3 April in half the world and 4 March in the other.
  • PUBLIC HOLIDAYS in the date calculator: they differ by country, sometimes by region inside one country, their dates move every year, and a holiday falling at a weekend often produces a substitute day decided case by case. A frozen list would be wrong within twelve months, and this project is aimed at a worldwide audience. So the working days counted run Monday to Friday, without exception, and it says so on the page.
  • THE DIDOT TYPOGRAPHIC POINT in the unit converter, and it is the most revealing exclusion of the lot: no metrology body defines it, and the books quoting it give four different values. When four secondary sources contradict each other and no first-hand source exists, there is nothing to copy. The web point, on the other hand, is exactly one seventy-second of an inch, and it says so in black and white in a specification.
  • PASSWORD PROTECTION FOR A ZIP ARCHIVE, in both directions: the format's historic encryption has been broken since 1994 by a published attack, and the modern one is a proprietary extension with several variants. We would do heavy work to deliver a protection we could not honestly call strong. The encryption tool in the security corner solves the real problem, and it shows its whole method.

The PDF corner's judgement calls, and the evidence behind them

Three decisions were taken to open the PDF corner, and each one costs something. Here they are, with what the checking actually established. A judgement call that does not say what it rests on is not a judgement call, it is an opinion.

FIRST DECISION: THIS SITE EMBEDS ONE LIBRARY, AND ONLY ONE. Writing a PDF by hand is unreasonable: it is a format of indirect objects, cross-reference tables and compressed streams, where a one-byte mistake makes the file unreadable. This is the exception the project's doctrine allows, and it is the only one taken. The code is SERVED BY US, never by a content delivery network: the PDF corner's pages load it from this site, its version is frozen into the file name so that an upgrade cannot be silent, its free licence is served next to it, and its exact weight is measured on disk at every build of the site, a little further down this page.

We checked one more thing, by machine: this file contains NO network call, not one, and the content lock re-checks it at every build, on the raw file, without even stripping the comments. An embedded library is checked like a tool, and more severely still.

SECOND DECISION: THE VERSION. The library named by the original doctrine has received no fix since November 2021 and its author has been unreachable since May 2024: we took the maintained continuation, under the same free licence. Between two versions of that continuation we did not take the more settled one but the more recent, for a precise reason: the earlier version built a protected document's internal identifier from the TIME of saving, hashed. Such an identifier can be recovered by brute force, so it would have dated every encrypted file to the millisecond. On a site whose promise is that nothing leaks, that was disqualifying. The version we kept draws that identifier at random.

THIRD DECISION, AND IT IS THE ONE THAT COSTS MOST: A PDF PASSWORD IS NOT AT THE STANDARD'S BEST LEVEL, AND WE DISPLAY THAT BEFORE THE ACT. PDF knows two ways of doing AES-256: revision 5, published by Adobe in 2008, and revision 6 of the PDF 2.0 standard. The encryption algorithm is the same; what changes is password verification. Revision 5 does it in a single computation, revision 6 deliberately slows it down, and published measurements from attack tools show four to five orders of magnitude difference in trial speed. The library only writes revision 5, which is also the only one the PDF 2.0 standard deprecates.

We could have written “AES-256” and said nothing more, as most sites offering this gesture do. We chose to display the revision, the key length and the way the key is built BEFORE the button is clicked, and to point towards building a real passphrase. With a short word this tool protects nothing; with a phrase of several randomly drawn words it really does. The difference is in your hands, provided somebody told you.

ONE MEASURED TRAP, AND IT WOULD HAVE BEEN INVISIBLE. When an encrypted document is saved a certain way, this library leaves the document's title, author and software READABLE IN THE CLEAR inside the protected file: you can see them in a plain text editor. We found this by reading back the bytes of our own output files, not in any documentation. So the tool saves in the only way that does not leak, it removes the identity card before encrypting, and the test lock now searches for those values in the clear in EVERY produced file. A check that only read the code would have seen nothing.

The embedded libraries

The house rule is zero dependency. A library may be embedded by exception, when writing the code by hand would be unreasonable: never from a third-party server, always at a pinned version, licence checked and weight stated here.

@cantoo/pdf-lib 2.8.1

the PDF corner · Licence MIT · 661.4 KB

Writing a PDF by hand is unreasonable: it is a format of indirect objects, cross-reference tables and compressed streams, and a one-byte mistake makes the file unreadable. This is the exception the doctrine allows, and it is the only one. This library is the MAINTAINED continuation of pdf-lib, whose last release dates from November 2021: we chose the living code. The version is frozen in the file name, the MIT licence is served next to it, and the code is here, with us: the PDF corner pages load it from this site, never from anywhere else. We checked one more thing, by machine: this file contains NO network call, not one, and the content lock re-checks it at every build.

https://github.com/cantoo-scribe/pdf-lib

The matrix's sources

Every line in the matrix was checked against a public source. Here they are, so the check can be redone without us.