Hoe lokale bestandsverwerking in een browser werkt
Als er niets wordt geüpload, wat doet het werk dan eigenlijk – en waar?
Wat “lokaal” hier betekent
Een gewone online converter is een website met een upload-endpoint. Je bestand wordt verstuurd naar een machine waar jij geen controle over hebt, daar verwerkt, enige tijd bewaard en als download weer aangeboden. Lokale verwerking schrapt het middenstuk van die zin: de code die je bestand leest, draait in het browsertabblad dat je al open hebt, op je eigen processor, en het resultaat wordt teruggeschreven naar je eigen schijf.
De site wordt nog steeds over het netwerk opgehaald – HTML, stylesheets, scripts en WebAssembly-modules komen allemaal van een server, net als bij elke webpagina. Het verschil zit in de richting. Programmacode komt naar beneden; jouw bestand gaat niet omhoog.
De browser bevat de onderdelen al
| Functie | Wat het levert |
|---|---|
| File- en Blob-API's | De bytes lezen van een bestand dat de gebruiker koos of neerzette, zonder formulierverzending |
| Web Workers | Zwaar werk op een achtergrondthread draaien zodat de interface blijft reageren |
| WebAssembly | Gecompileerde codecbibliotheken in C, C++ of Rust bijna op native snelheid draaien |
| Canvas en OffscreenCanvas | Afbeeldingen decoderen, tekenen, schalen en opnieuw coderen |
| WebCodecs | De hardwareversnelde video-encoders en -decoders van de browser zelf aanspreken |
| WebGPU | Modelinferentie en parallel pixelwerk op de grafische processor draaien |
| File System Access | Het resultaat direct wegschrijven naar een locatie die de gebruiker kiest, waar dat ondersteund wordt |
Niets hiervan is exotisch. Het is hetzelfde platform waarop spreadsheets, ontwerptools en games in een tabblad draaien. De enige ongebruikelijke keuze is weigeren daar een server aan toe te voegen.
De weg die een bestand aflegt
- Je kiest een bestand. De browser geeft de pagina een handle daarnaartoe – geen kopie, een verwijzing.
- De pagina leest de eerste bytes om het echte bestandstype aan de signatuur te herkennen, in plaats van op de extensie te vertrouwen.
- De pagina schat in hoeveel geheugen de klus nodig heeft, en weigert het werk of zet het in de wachtrij als dat meer is dan het apparaat veilig kan leveren.
- De bytes worden overgedragen aan een Web Worker. Bij het overdragen van een ArrayBuffer verhuist het eigendom in plaats van dat er gekopieerd wordt, zodat een groot bestand niet twee keer in het geheugen staat.
- Binnen de worker doet een WebAssembly-codec of een platform-API het eigenlijke decoderen en coderen.
- Het resultaat komt terug als bytes, wordt in een Blob verpakt en aan jou aangeboden als download of weggeschreven naar een locatie die jij kiest.
- De tijdelijke URL voor die Blob wordt ingetrokken en de buffers worden vrijgegeven.
Waarom WebAssembly het onderdeel is dat het verschil maakte
Beeld- en videocodecs zijn decennia aan zorgvuldig geoptimaliseerde C. Ze herschrijven in JavaScript was nooit realistisch. WebAssembly is een portabel binair instructieformaat dat browsers in een sandbox uitvoeren op een snelheid die dicht bij native code ligt, en dat betekent dat die bestaande bibliotheken ongewijzigd gecompileerd en naar de browser gestuurd kunnen worden.
De sandbox is net zo belangrijk als de snelheid. Een WebAssembly-module heeft geen vanzelfsprekende toegang tot je bestandssysteem, je netwerk of je andere tabbladen. Hij ziet het geheugen dat de pagina hem aanreikt en verder niets. Een kwaadaardige of simpelweg buggy codec kan niet gaan zwerven en iets lezen wat hem niet is gegeven.
Wat het netwerk nog wél raakt, en waarom dat niet jouw bestand is
Drie dingen komen over het netwerk binnen: de pagina zelf, de engine voor de tool die je opende en – bij achtergrondverwijdering – de modelgewichten. Alle drie zijn eigen statische assets van FileSlimmer, opgehaald van de eigen origin van FileSlimmer voordat er ook maar één byte van jou wordt gelezen. Het zijn downloads, ze zijn cachebaar, en na het eerste gebruik kunnen ze uit de cache van de browser zelf komen, zonder netwerk.
Alles na dat punt is lokaal. De engines krijgen bestandsbytes uitsluitend via postMessage van de pagina; ze krijgen nooit een URL om iets naartoe te sturen, en een content security policy beperkt waar de pagina verbinding zou kunnen maken, zelfs als code dat zou proberen.
De afwegingen, ronduit gezegd
| Overweging | In je browser | Op een server |
|---|---|---|
| Waar je bestand heen gaat | Nergens heen | Naar een machine waar jij geen controle over hebt |
| Snelheid | Wat je apparaat aankan | Wat de beheerder heeft betaald |
| Heel grote bestanden | Begrensd door het browsergeheugen | Begrensd door de limieten van de beheerder |
| Werkt offline | Ja, zodra de engine in de cache staat | Nee |
| Exotische formaten | Alleen wat naar WebAssembly compileert | Alles wat de beheerder installeert |
| Batch van duizend bestanden | Beperkt door het apparaat | Meestal geschikter |
Lokale verwerking is niet overal beter. Ze is beter wanneer het bestand privé is, wanneer het apparaat krachtig genoeg is en wanneer het werk in het geheugen past. Een server is beter wanneer je veel meer moet verwerken dan één machine kan bevatten. Helder hebben in welke situatie je zit, is nuttiger dan volhouden dat één aanpak overal wint.
Wat hier niet wordt beweerd
Dit is een uitspraak over wat deze applicatie doet. Het is geen uitspraak over je browserextensies, die de inhoud van elke pagina die je opent kunnen lezen, noch over je besturingssysteem, dat elk bestand dat je aanraakt kan inspecteren, noch over je netwerkaanbieder, die kan zien dat je een site hebt bezocht. Die vallen buiten het bereik van elke website, en een tool die je iets anders vertelt, overdrijft haar zaak.
De bewering is smal en controleerbaar: de bestanden die je selecteert worden lokaal in deze browser verwerkt en worden door FileSlimmer niet geüpload. De volgende gids legt uit hoe je dat zelf verifieert in plaats van het te geloven.
Tools hiervoor
Bronnen
- W3C — File API
- W3C — WebAssembly Core Specification
- WHATWG — HTML Standard, Web Workers
- W3C — WebCodecs