The engineering, honestly described — including where the compromises are.
The image compressor is a Rust crate of ours compiled to WebAssembly. It ships its own PNG encoder — adaptive per-row filtering, zopfli deflate and palette quantisation with luminance-ordered entries — plus a JPEG encoder with progressive coding, optimised Huffman tables and chroma subsampling control. WebP and AVIF go through the browser's own encoders, because libwebp is already compiled into it and beats anything we could ship.
It runs in a pool of Web Workers, one per core. That is not only a privacy decision: this server has four slow vCPUs, and pushing image work onto the visitor's machine is the only way a batch of five hundred photos can be instant rather than queued.
The 3D pipeline is ours too — STL, OBJ, PLY, OFF and glTF/GLB parsers, a Garland-Heckbert quadric error metric simplifier, vertex welding and coordinate quantisation. Nothing on this host could do it: Blender is a 500 MB Python application and MeshLab is a GUI.
These need ffmpeg, ghostscript and the real compressors, so they upload. Files are spooled straight to disk rather than buffered in memory, which is why there is no size limit, and they are deleted an hour later.
Heavy encodes take a permit from a small semaphore. Oversubscribing four cores with six concurrent encodes does not finish six jobs sooner — it finishes all six later, and every one of them looks stalled.
Video previews encode a three-second sample through byte-identical ffmpeg arguments to the real job. Audio previews do the same with an eight-second clip. PDFs and 3D models are processed in full whenever that is affordable, which makes the reported size exact rather than extrapolated.
Where a number really is an estimate, it says so. Extrapolating a video's size from three seconds is genuinely unreliable — a busy scene costs more than a still one — and pretending otherwise would be worse than admitting it.