How big a STEP file can an online converter take? The upload ceiling, and what a browser tab does instead
A converter that runs the conversion on its own servers has to publish a limit, because the compute is its bill; a converter that runs in your browser tab has no such limit to publish, because the file never leaves your machine. This page lays out the three controls an upload service cannot avoid — a ceiling, a batch, a retention window — and then replaces them with the numbers this site actually measures. Every figure here is re-run by the test suite before the page can publish.
The short answer
The file-size limit on an online STEP converter is a billing decision, not a property of STEP files. A service that uploads your file and converts it on its own hardware pays for that hardware, so it does three things at once: it publishes an upload ceiling, it accepts a batch as a single archive so many files become one transfer, and it keeps the result for a fixed window. Those three are not separate features; they are the same fact — compute runs somewhere you are not — seen from three sides. A converter that parses the file inside your browser tab has nothing to meter. The model never leaves the machine, so the only ceiling is your own memory and the tab’s patience, and there is no window for a server-side copy to expire, because no copy is ever made. This site runs the second kind: the largest file it measures is 433,606 bytes of STEP — an 18-part assembly — and its full Fine tessellation into 21,116 triangles finishes inside one tab with nothing uploaded.
The three controls an upload service cannot avoid
A service that converts on its own servers carries three constraints that a browser-side converter simply does not have. They arrive together, and none of them is about geometry.
| The control | Why it exists |
|---|---|
| A single-file ceiling | Every conversion spends processor time the service pays for. A ceiling is how it bounds that spend per job, so the limit tracks a pricing decision and not a property of the STEP format. |
| A batch rule | When you have several files, collecting them into one archive turns a count into a single transfer the same ceiling governs. The batch is a shipping convenience for a job that runs elsewhere. |
| A retention window | A copy of your model now sits on their server, so it must be given a lifetime: a fixed window, a long-term link that expires within a day, and a delete button to end it early. The window exists only because the copy does. |
Read together, the three describe one arrangement: your file travelled, so someone has to bound how much machine they will spend on it and how long they will hold it. The upload-safety page ranks the promises that follow from that arrangement, from a deletion policy up to an architecture where no upload happens at all; the one sentence worth carrying here is that a window is a retention promise, and retention only exists when a copy does. What this page adds is the other half: how much capacity exists when the copy never does.
Why a server publishes a ceiling at all
The ceiling is easiest to understand as an old problem. An early upload service metered its free tier by machine time and said so outright: it capped free files at a number of polygons and gave the reason in money, because processing time cost the operator money (why the upload existed in the first place). The size of the ceiling has changed since then; the reason for having one has not. Wherever the tessellation runs, somebody’s hardware does the work, and when that hardware is a server the operator owns, the ceiling is the lever that keeps the bill bounded. That is why a capacity limit on a server is a policy number that can move, and why two services can publish different ceilings for the same file without either being wrong about STEP.
What replaces the ceiling in the tab, measured
Move the same work into the browser and the ceiling has nothing left to bound. This site ships the OpenCASCADE kernel as a WebAssembly file of 7,604,031 bytes (7.25 MiB), fetched once per session from this site’s own folder and then run in a worker inside your tab. Once the kernel is in the tab, the only limit on the size of a model is how much work the machine in front of you will do — which is a resource, not a purchased ceiling, and nobody can set it but you.
The numbers this site prints are the ones it measures, and the suite refuses to publish the page if any of them move. A flat 10 mm test cube stays at 12 triangles and exactly 684 bytes at every quality setting. The largest input the project measures is an 18-part assembly, 433,606 bytes of STEP on disk; at Normal it converts to 7,372 triangles and a 368,684-byte STL, and at Fine it runs to 21,116 triangles — a 1,055,884-byte STL under the identity 84 + 50 × triangles. All eighteen parts convert in the tab in one pass, with nothing uploaded. There is no ceiling printed above those numbers because there is no server to print one from; what stands in its place is your machine, and the honest way to state its limit is to point at a measured file rather than to promise a maximum.
One number worth separating from the ceiling: the identity 84 + 50 × triangles means the output size is fixed by the triangle count, not by the input file. That is a different question from how large an input can be, and the page about STL file size owns it.
The direction where capacity was never the sell
Capacity limits belong to one direction only. In the reverse direction — turning an STL back into an editable STEP — there has never been a ceiling to publish, because the work is done by a person rather than a server, and a person is sold in files and days. A 2020 capture of a reconstruction service priced exactly that way: a rate per file and a delivery measured in a working day, with no capacity cap anywhere on the page (what an outsourced rebuild cost). Size was never the constraint there either — the constraint was an engineer’s hours. It is only the machine direction, the one this site runs, where someone used to own the hardware and had to bound what it did.
Questions this page answers
Is there a file-size limit on an online STEP converter?
A converter that runs on its own servers has to publish one, because the compute is its bill: a tool this project read in October 2026 states an upload ceiling measured in hundreds of megabytes. A converter that runs in the browser has no upload ceiling to publish, because there is nothing to upload — the boundary is the machine in front of you, and this site's own largest measurement is a 433,606-byte 18-part assembly that tessellates to 21,116 triangles in a single tab.
How many STEP files can an online converter take at once?
Upload services usually answer this by collecting a batch into one archive, which turns a count of files into a single transfer the same ceiling applies to. The count is a shipping convenience tied to compute that runs on their hardware. A tab does the opposite: this site's converter takes one file at a time and keeps no batch queue, because a queue only makes sense when you have somewhere to send the files — and here the files never move.
Does an upload ceiling tell me how big a file I can really convert?
No. On a server the ceiling is a billing decision about someone else's hardware, not a property of the STEP format, so the same model that is too large for one service may pass on another and the ceiling moves with pricing and policy. The useful number is the one you can check on your own machine, which is why this page prints what this site measures rather than what any service promises.
What is the real size limit on this converter?
Not a size — a resource. The whole OpenCASCADE kernel ships as a 7,604,031-byte WebAssembly file that runs in the tab, so the ceiling is the memory of your own machine and how long you will wait. The largest file this project measures is an 18-part assembly of 433,606 bytes, whose Fine tessellation is 21,116 triangles and a 1,055,884-byte STL, done in one tab. Nothing is uploaded, so there is no ceiling to publish and no window for a copy to expire.
Where these numbers come from
- 7,604,031 bytes — the length of the shipped WebAssembly kernel file on disk; the test suite reads 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 at Normal and 21,116 triangles → 1,055,884 bytes at Fine — the 18-part test assembly’s STEP length on disk, its triangle counts at two presets, and the resulting STL lengths under the same identity.
- The upload ceiling, the batch and the retention window — described from direct October 2026 reads of tracked tool pages recorded in this project’s research log. They are stated only in qualitative terms here; no megabyte figure or hour window from a third party is printed, because none of those can be re-run by the test suite.
- What we do not claim — we publish no upper size a STEP file may reach, because the honest boundary is the memory of the machine running the tab and not a number anyone can promise ahead of time. The verification page owns the format rejection list; this page links to it rather than repeating it.
npm testThe command above re-runs every number on this page. The upload-safety page owns the promise ladder and the one-minute network check; the upload-history page owns why the old ceiling existed; the rebuild-cost page owns the per-file human direction; the STL-size page owns the output-side size question; and the converter is where a STEP file meets the kernel, for free, in the tab.