Skip to content
Dexta Studio
Get Started

How Dexta Studio works

All 70 tools run inside your browser tab. This page explains what that means in practice — which engine does the work, what happens to your file, what the site does collect, and where processing on your own device runs out of room.

Processing happens where the file already is

Most online media tools work by uploading. You hand your file to a server, it queues, something happens to it, and you download the result. That costs the operator real money per file, which is why such sites tend to arrive with watermarks, size caps and subscriptions — and it means a copy of your file sits on a machine you know nothing about.

Browsers no longer need that. WebAssembly runs compiled C at close to native speed, and the Canvas and Web Audio APIs give direct access to pixels and samples. So Dexta Studio ships the software to your device instead of shipping your file to ours.

What happens to your file

Every tool follows the same five steps. No step in this sequence sends your file anywhere.

  1. 01

    Select a file

    Drag it in or pick it from the file dialog. Nothing is transmitted at this point.

  2. 02

    Into the browser tab

    The file is read into this tab's memory as bytes. It exists nowhere else.

  3. 03

    Processed on your device

    The engine for that tool runs on your own CPU and produces the result.

  4. 04

    Result in memory

    The output is held as a blob in the same tab, with a temporary local URL.

  5. 05

    Download

    You save it. Closing the tab discards both the input and the output.

Which tools follow this model

All 70 of them. There is no upload endpoint anywhere in the application and no server-side processing path — every video, image, PDF and audio tool works exactly as described above.

The one exception, and it is not your file

The video editor can search free stock libraries. If you use that panel, your search term is sent to our worker so it can query Pixabay or Jamendo, and any clip you choose is streamed back through the same worker. That is media coming to you. Files you brought are never part of the request, and the panel does nothing unless you open it.

What does the work

The method varies by tool, because the right engine depends on the format. Counts come from the tool registry.

  • FFmpeg, compiled to WebAssembly

    39 tools

    Decodes, filters and re-encodes video and audio. It is the same FFmpeg desktop software uses, compiled to WebAssembly so it runs inside the tab. Dexta ships the single-thread build, which is slower than the multi-threaded one but does not require a security header that would break other parts of the page.

  • Canvas 2D

    15 tools

    The browser's own drawing surface. Images are decoded into it, transformed, and written back out with toBlob — the shortest path available, with no library in between. It is also what renders PDF pages to pictures.

  • pdf-lib

    12 tools

    Reads a PDF's page objects and writes new documents. Merging, splitting, rotating, reordering and extracting copy pages across rather than re-rendering them, which is why those operations are lossless and keep text selectable.

  • pdf.js

    3 tools

    Mozilla's PDF renderer, used where a page has to become a picture: thumbnails, previews, PDF-to-image conversion, and the page rasterisation that PDF compression relies on.

Supporting browser APIs

  • Web Audio API

    Decodes audio to draw waveforms, and to find beat positions for the reel templates. It is used for analysis and display only — the actual encoding is done by FFmpeg.

  • Web Workers

    Two of them. pdf.js runs its parser in a worker served from this site, and FFmpeg.wasm starts its own. Both keep heavy work off the main thread so the interface stays responsive while a file is processing.

Your file and our telemetry are two different things

People often hear “we collect analytics” and assume that includes what they were working on. It does not, and the distinction is worth stating precisely rather than in a slogan.

File processing

What happens to the thing you dropped in.

  • Your file is read into the tab's memory and processed by your own device.
  • It is not sent anywhere: there is no upload endpoint in the application and no request carries file data.
  • The result stays in the tab until you download it.
  • Closing or reloading the tab discards both. Nothing is written to disk unless you save it.

Website telemetry

What the site itself records and requests.

  • When a tool runs we record five values: the category, which tool, what happened (opened, exported or errored), whether it succeeded, and how long it took. No cookie and no identifier are involved.
  • The page loads Google AdSense once you accept advertising cookies. That request carries your IP address, browser and referring page, as any ad-supported site does.
  • Video and audio tools download the FFmpeg engine from the jsDelivr CDN on first use, which means jsDelivr sees that request.
  • If you search the stock library, your search term goes to our worker. Your own files do not.

Deliberately not claimed: that the site is “100% private”, that it is “completely secure”, or that nothing is collected. The right-hand column is real, and describing it accurately is more useful than a slogan. What happens to your file, category by category goes through this in more detail, and the privacy policy is the document that governs it.

Where this approach runs out of room

Working in the browser does not remove the cost of processing — it moves it to your device. These are the consequences.

Large files

There is no size cap in the application, which also means no warning before you reach yours. The whole file is held in memory while it is worked on, so the ceiling is what the tab is allowed rather than a number we set.

Memory

Decoded media is far larger than the compressed file suggests — a few seconds of 1080p can occupy hundreds of megabytes once expanded. A few operations need the entire clip in memory at once, reversing in particular, and those are genuinely limited to short files.

Processor

Encoding speed is your CPU's speed. Re-encoding every frame of a long video takes minutes rather than seconds, and the FFmpeg build here uses a single thread, so it gets one core rather than all of them.

Phones and tablets

Everything runs, and mobile browsers cap how much memory a tab may use far more tightly than a desktop one. Large videos are where you will notice: a file that processes fine on a laptop can exhaust a phone and reload the page.

Browser support

Current versions of Chrome, Edge, Safari, Firefox and Brave all work. The requirement is WebAssembly and the Canvas and Web Audio APIs; anything modern enough to have those will run the tools.

How long it takes

Trimming, rotating and muting finish in seconds because they touch only part of the file. Compressing and converting rebuild every frame and take proportionally longer. The first video or audio job of a session also downloads the FFmpeg engine, roughly 30 MB, before it can begin.

Some things are simply not possible this way. HEIC and camera RAW cannot be reliably decoded by a browser, so those formats are not supported. Where a limit applies to one tool in particular, it is written on that tool's own page rather than buried here.