Is it safe to upload a STEP file to an online converter? Three promises and one architecture

Every converter answers the safety question with a promise, but the promises are not equivalent: some cover what happens to your file after it has been uploaded, and one kind covers whether the upload happens at all. This page ranks those promises, shows what this site’s zero-upload architecture is actually made of in measured numbers, and gives you a one-minute check you can run on any converter — including this one.

The short answer

The safe arrangement is not a stronger promise, it is a missing upload: if the file never leaves your machine, there is no copy on anyone else’s server to lose, leak, retain or mis-handle. A converter that uploads your STEP file can only make promises about its copy afterwards — delete it after a while, not share it, not keep it. Those are retention policies, and policies can change, misfire or be narrower than the sentence that states them. A converter that parses the file in your browser tab makes a different kind of claim entirely: the transport itself does not happen. The question to ask of any converter is therefore not what do you do with my file but does my file reach you at all — and that question has a technical answer you can check yourself, in your own browser, in about a minute.

Four rungs, from policy to architecture

Privacy claims from conversion services sort into four rungs. Each rung is a different kind of statement, and the difference between them is exactly the difference between a policy and an architecture.

The four rungs of a privacy promise, what each one actually covers, and what it cannot tell you
Rung 1 · Delete afterwards	“We delete your file once conversion finishes.” The file has already travelled; the promise governs its copy on the server. It cannot tell you who handled the file in transit, or whether the deletion is verified.
Rung 2 · Do not store	“We do not store your files.” Still an upload: the promise is about retention, not transport, and retention windows are set by the same party that receives the file.
Rung 3 · No upload at all	“Conversion happens locally; the file is not uploaded.” An architecture claim, not a policy. It can be true, and it is checkable — but check whether the claim comes with anything you can verify.
Rung 4 · Claim + evidence	The architecture claim plus two things that make it checkable: a named list of every request the pages make, and an automated test that re-checks the claim on every build. This is the rung this site occupies.

Policy versus architecture. The first two rungs govern a copy of your file that already sits on someone else’s server. The third rung claims the copy never comes into existence; the fourth adds the evidence that lets you check the claim yourself instead of taking it on faith.

How to read a promise in one sentence

The discriminator is a single distinction: transport or retention. A sentence about deleting, not keeping, not storing, or windows of availability is a retention sentence — whatever it says, the upload has already happened and the speaker holds your file. A sentence about where the parsing happens — in your tab, on your machine, locally — is a transport sentence. Only the transport kind can settle the safety question, because a retention promise, however sincere, is still a description of how long strangers hold your geometry. The workflow page keeps the short version of this ranking beside the conversion steps; this page is the full reading.

Two follow-up questions separate the transport claims from each other. Does the claim come with a named request list — the stylesheet, the script, the engine file — so you can compare it against what your browser actually fetches? And is the claim re-verified by anything, or restated by hand? A promise that a build machine re-tests before every publish is a different object from a paragraph of reassurance that no process ever re-checks.

What this site’s rung is made of

The architecture claim here is specific enough to be falsifiable, so it comes with its numbers. The geometry kernel — OpenCASCADE, the same kernel desktop CAD packages are built on — ships as a single WebAssembly file of 7,604,031 bytes (7.25 MiB) served from this site’s own folder, fetched by a worker thread once per tab and then served from cache. When you drop a file on the converter, the browser reads the bytes with the File API inside this tab, the worker tessellates the model with that kernel, and the STL you download is written by your own browser. Nothing about your file is in any request, because no code on this site sends file bytes anywhere.

The numbers behave like any other number on this site. A flat 10 mm test cube converts to 12 triangles and lands as exactly 684 bytes at every quality setting, and any binary STL obeys the identity 84 + 50 × triangles, so you can confirm a download is intact from its file size alone. The 18-part test assembly this site converts everywhere measures 433,606 bytes of STEP on disk and comes back as 7,372 triangles — a 368,684-byte STL — with all eighteen parts converted in the tab in one pass. Every request the pages can make is named in the privacy policy’s request table, your file included, listed as nowhere; that table is the authoritative list and this page does not restate it.

What makes the claim re-verified rather than restated: the project’s browser test suite runs a conversion and requires that it makes no request beyond the page origin, on every test pass, and the publish gate refuses to build if the checks fail. The promise is re-tested by a machine before you ever read it — which is the whole difference between rung 3 and rung 4.

Check any converter in one minute

The method works on every converter, including this one, and it needs nothing but your browser:

Open the network panel. Developer tools, Network tab, clear it, then run a conversion on a file you do not care about.
Look for the upload. An upload is a request whose transferred size roughly equals your file’s, sent to a domain that is not the page’s own. A local converter shows only same-origin fetches: the page, its script, and the engine it pulls from its own folder.
Read the promise against what you saw. If the network panel shows an upload, the strongest promise the service can truthfully make is a retention promise, whatever its marketing says. If it shows no upload, you have verified the architecture claim yourself — the claim is now your observation, not their sentence.

Run it here and the panel will show same-origin requests only: the stylesheet, the page’s script, the worker, the engine glue, and the 7,604,031-byte kernel — and no request that contains your file, because there is nowhere for such a request to go.

Where the tracked sites stand, as read in October 2026

Of the three sites this project tracks, two carry claims this page can name precisely. imagetostl’s STEP tool page states the transport plainly: the file is uploaded to their servers and converted there, with the result kept for a fixed window and a delete button provided — the transport stated out loud, the safety handled as retention. convert3d’s homepage carries a rung-3 claim: conversion happens locally in your browser and files are not uploaded to any server; its STEP page itself is a two-row compatibility table with no privacy section, so the claim and the tool live on separate pages, and the claim comes without a per-request list a visitor could check against. The third benchmark service pairs its converter with a blog page devoted to confidentiality; every promise across both pages is a retention promise, which is the honest ceiling for an upload-based service. These reads are dated snapshots, and every site can move — the ladder above is the stable part, not where anyone stands on it today. None of these reads is a criticism of geometry quality; a rung-2 service can convert well. The ladder measures one thing only: how much of the safety question the arrangement settles before any promise has to be trusted.

Questions this page answers

Do online converters keep a copy of my STEP file?

It depends entirely on where the conversion runs. A service that uploads the file can only promise what happens to the copy afterwards: deletion after a fixed window, no sharing, no retention. A converter that parses the file in your browser tab never has a copy to keep, because the file bytes never leave your machine. The promise to look for is not about deletion, it is about transport: if the file is never uploaded, there is nothing to retain, and no deletion policy to trust.

How can I tell whether a converter uploads my file?

Open your browser's developer tools, switch to the network panel, and run the conversion while watching the requests. An upload shows up as a request whose size equals your file and whose destination is not the page you are on. A converter that works locally shows only same-origin requests: its own page, its own script, and the engine file it fetches from its own folder. The same panel is also the fastest way to read a promise: a sentence about deleting files describes retention, and a sentence about where parsing happens describes transport.

Is browser-side conversion safe for confidential STEP files?

It is the only arrangement in which confidentiality is a property of the architecture rather than of a policy. On this site the whole OpenCASCADE kernel ships as a 7,604,031-byte WebAssembly file served from the site's own folder, a worker thread in your tab runs the conversion, and the browser test suite re-checks on every build that a conversion makes no request beyond the page origin. The trade is honest: the conversion runs on your hardware, so a slow machine converts slowly, and no server absorbs the work for you.

What should I check before trusting a converter's privacy promise?

Three things, in order of strength. First, whether the promise covers transport or only retention: deletion after conversion leaves the upload itself untouched. Second, whether the site names its requests: a page that lists every request it makes, including the engine file and the absence of your file, can be checked line by line in the network panel. Third, whether the claim is re-verified: this project's test suite re-runs the origin-only request check before every publish, so the promise is re-tested on each build rather than restated by hand.

Where these numbers come from

7,604,031 bytes — the length of the shipped WebAssembly kernel file on disk; the test suite takes the size from the file itself on every pass and requires the page to print that count, not a rounded one.
12 triangles, 684 bytes — the flat 10 mm test cube converted at every preset, and the identity 84 + 50 × triangles closing on it: 84 + 50 × 12 = 684.
433,606 bytes → 7,372 triangles → 368,684 bytes — the 18-part test assembly’s STEP length on disk, its triangle count at Normal, and the resulting STL length under the same identity.
No request beyond the page origin — asserted by the browser test suite, which injects a file, runs a conversion, and inspects the requests the page made; the publish gate re-runs the non-browser checks before any build ships.
The four rungs and the October 2026 reads — the ranking is this page’s own analytical frame; the dated site descriptions come from direct reads of those pages recorded in this project’s research log, with no sentence taken from them.

npm test

The command above re-runs every number on this page. The privacy policy owns the named request table; the workflow page keeps the promise ranking as a short answer beside the conversion steps; the verification page owns the six checks that confirm a conversion from the bytes alone, no matter whose converter produced it; and the converter is where you can run the one-minute check and watch nothing leave the tab.