How file processing works

A step-by-step account of what happens to a file you drop into one of the 60 tools — where it is processed, which requests the page makes, and what is stored afterwards. Everything below was checked against the source and confirmed by recording the network activity of a real run.

What happens, category by category

Steps 1, 2, 4 and 5 are the same everywhere. Step 3 is where the categories genuinely differ, so it is worth reading even if the rest looks familiar.

Image tools

1. File selection: You drag a file in or pick it from the file dialog. The browser hands the page a reference to it. Nothing is transmitted at this point, and a file of the wrong type is refused before it loads.
2. Browser processing: Your browser's Canvas 2D API. The file is decoded with createImageBitmap, drawn onto a canvas, and encoded back out with toBlob. No library is downloaded, which is why image tools finish almost instantly.
3. Network requests: No third partyNone. A recorded run of Compress Image made no third-party request at all — the only same-origin request was the usage counter after the export finished.
4. Result generation: The output is produced as a blob in the same tab and given a temporary local address. It is not written to disk and not sent anywhere.
5. Download: The download link points at that in-memory blob, so saving the file is a copy from your own tab to your own disk. Closing the tab discards both the input and the result.

Compress Image Resize Image Convert Format All image tools →

PDF tools

1. File selection: You drag a file in or pick it from the file dialog. The browser hands the page a reference to it. Nothing is transmitted at this point, and a file of the wrong type is refused before it loads.
2. Browser processing: pdf-lib writes the new document, and pdf.js renders pages when a picture is needed. Both ship with the site; pdf.js runs its parser in a worker served from dextastudio.com, not from anyone else.
3. Network requests: No third partyNone. A recorded run of Compress PDF fetched /pdf.worker.min.mjs from our own origin and made no third-party request.
4. Result generation: The output is produced as a blob in the same tab and given a temporary local address. It is not written to disk and not sent anywhere.
5. Download: The download link points at that in-memory blob, so saving the file is a copy from your own tab to your own disk. Closing the tab discards both the input and the result.

Merge PDF Compress PDF Sign PDF All pdf tools →

Video tools

1. File selection: You drag a file in or pick it from the file dialog. The browser hands the page a reference to it. Nothing is transmitted at this point, and a file of the wrong type is refused before it loads.
2. Browser processing: FFmpeg, compiled to WebAssembly, running in a worker inside the tab. It decodes, filters and re-encodes every frame on your own CPU.
3. Network requests: One third partyOne, and only the first time you use a video or audio tool in a session: the browser downloads the FFmpeg engine (about 30 MB) from the jsDelivr CDN, then reuses the cached copy. That is a file coming to you. Your video is not part of the request — jsDelivr sees a request for a library, the same as any site loading a script from a CDN.
4. Result generation: The output is produced as a blob in the same tab and given a temporary local address. It is not written to disk and not sent anywhere.
5. Download: The download link points at that in-memory blob, so saving the file is a copy from your own tab to your own disk. Closing the tab discards both the input and the result.

Compress Video Trim Video Convert Video All video tools →

Audio tools

1. File selection: You drag a file in or pick it from the file dialog. The browser hands the page a reference to it. Nothing is transmitted at this point, and a file of the wrong type is refused before it loads.
2. Browser processing: The same FFmpeg WebAssembly build the video tools use. The Web Audio API is used alongside it to draw waveforms and find beats — for display and analysis only; it does no encoding.
3. Network requests: One third partyThe same single engine download from jsDelivr, shared with the video tools. If you have already used a video tool this session, the audio tools make no third-party request at all.
4. Result generation: The output is produced as a blob in the same tab and given a temporary local address. It is not written to disk and not sent anywhere.
5. Download: The download link points at that in-memory blob, so saving the file is a copy from your own tab to your own disk. Closing the tab discards both the input and the result.

Convert Audio Compress Audio Trim Audio All audio tools →

Every kind of data, and where it goes

Only entries that could be verified in the code are listed. Nothing here is inferred from how similar sites usually behave.

Data handled by Dexta Studio, where it is processed, whether it is stored, and whether a third party is involved
Data	Where processed	Stored?	Third party?
Your video, image, PDF or audio file	Your device, in the browser tab	No — held in memory, discarded when the tab closes	No
The result you export	Your device	No — until you choose to download it	No
Settings you choose in a tool	Your device	No	No
Tool usage event: category, tool, action, success, duration	Our Cloudflare Worker	Yes — as anonymous aggregate counts	Cloudflare (our hosting)
Theme preference	Your browser	Yes — localStorage, on your device only	No
Cookie consent choice	Your browser	Yes — localStorage, on your device only	No
The FFmpeg engine (video and audio tools)	Downloaded to your device	Yes — in your browser's cache	Yes — jsDelivr CDN
Advertising requests, after you accept	Google's servers	Per Google's policies	Yes — Google AdSense
Stock library search term, if you use that panel	Our Worker, then the provider	No	Yes — Pixabay or Jamendo
Account details	—	None exist — there are no accounts	No
Payment details	—	None exist — nothing is sold	No

What was checked, and what was found

Each of these was answered by reading the implementation, then confirmed by recording every request a real export makes in a browser.

Uploads: None. There is no FormData anywhere in the codebase and no file or blob is placed in any request body. There is no upload endpoint to send one to.
API calls: Two, both same-origin. /api/event receives the usage counter. /api/stock/* proxies searches to Pixabay and Jamendo, and only runs if you open the stock panel in the video editor.
Analytics and telemetry: One anonymous event per tool run, sent to our own Cloudflare Worker and written to Cloudflare Analytics Engine. It carries the category, tool slug, action, whether it succeeded and how long it took. No file data, no identifier, no cookie.
Authentication: None. There is no sign-in, session, token or account anywhere in the application.
Storage: localStorage only, holding two values on your own device: your theme choice and your cookie consent choice. No IndexedDB, no server-side storage.
Payments: None. No payment processor is integrated and nothing is sold.
Cookies: Dexta Studio sets no cookies of its own. Google AdSense sets its own once you accept advertising in the consent banner; decline and the ad script is never loaded.

Two things this page deliberately does not say: that Dexta Studio is “100% private”, and that nothing is collected. The usage counter is real, advertising is real once you accept it, and the video and audio tools do fetch their engine from a CDN. Those are stated above rather than rounded off. What is accurate is narrower and more useful: your file is not uploaded, because there is nowhere in this application to upload it to.