Online Quantum Circuit Simulator: How It Works and Where It Stops

What a quantum circuit simulator computes

A quantum circuit is a list of instructions: start every qubit in the zero state, apply these gates in this order, then measure. A real quantum computer carries out those instructions on physical qubits. A simulator does something different. It is a classical program that keeps a mathematical description of the qubits and updates that description gate by gate.

That distinction matters for how you read the output. A simulator of this kind gives you the ideal answer: no noise, no drift, no readout error. It is the right tool for learning what a gate does, checking that a circuit prepares the state you intended, and finding mistakes before anything is sent to hardware. It is not evidence that a circuit will behave the same way on a real device, and nothing about it is faster than classical computing, because it is classical computing.

The state vector, and why it runs out of room

The most direct way to simulate a circuit is to store the full quantum state. For a register of qubits, that state is a list of complex numbers called amplitudes, one for every possible measurement outcome. One qubit has two outcomes. Two qubits have four. Every additional qubit doubles the list.

Applying a gate means updating that list. Measuring means converting amplitudes into probabilities. Because the simulator holds every amplitude, it can show you things a real machine never reveals directly: the exact probability of each outcome, the phase of each amplitude, and the state of any single qubit.

The cost is the doubling. A circuit that looks modest on screen can need more memory than a browser tab, or a laptop, can provide. This is the main reason every state-vector simulator has a qubit ceiling, and why that ceiling is low compared with the qubit counts quoted for hardware. It is a property of the method, not a shortcoming of one product.

The exception: Clifford circuits and stabilizer simulation

Some circuits do not need the full list of amplitudes. If a circuit uses only Clifford gates — Hadamard, the S phase gate, the Pauli gates X, Y and Z, CNOT, CZ, and SWAP — plus measurement, its state can be tracked with a compact table (a stabilizer tableau) whose size grows with the square of the qubit count instead of doubling. This is the Gottesman–Knill result, and it is why a classical computer can simulate much wider Clifford circuits than general ones.

Two limits come with it:

• Only Clifford gates. Add a single T gate, an arbitrary rotation, or a Toffoli, and the shortcut no longer applies. The circuit is a general circuit again and falls back under the state-vector ceiling.
• Samples, not amplitudes. A stabilizer simulator does not produce the amplitude list, because writing it out would bring back the exponential cost. What you get is a set of sampled measurement outcomes.

Clifford circuits are not a toy category. GHZ states, Bell pairs, and the syndrome-extraction rounds used in quantum error correction are all Clifford. But the gates that make a quantum computer more than classically simulable are exactly the ones this method leaves out, so a large Clifford result says nothing about how large a general circuit you can simulate.

What to look for in an online simulator

A few questions separate a useful tool from a demo:

• Does it tell you which method ran? A histogram from a full state vector and a histogram from sampling a stabilizer tableau are different kinds of result.
• Does it state its limits conditionally? One headline qubit number, with no mention of which circuits it applies to, usually describes the Clifford case only.
• Where does the computation happen? In your browser, on a server, or either depending on the circuit — and does the tool tell you before sending anything?
• Can you get your circuit out? A text format such as OpenQASM keeps your work portable.

How SwiftQuantum IDE handles this

SwiftQuantum IDE is a browser-based circuit editor and simulator. You sign in, drag gates from a palette onto qubit wires, and press run. The palette covers the Pauli gates, Hadamard, S and T, the Rx, Ry and Rz rotations, CNOT, CZ, SWAP, Toffoli, Fredkin, and measurement.

Engines. The simulation engines run in your browser:

• A JavaScript state-vector engine that runs in a background worker, so the page stays responsive during a run. This is the engine on the free plan.
• A WebAssembly state-vector engine on paid plans. It simulates the same kind of circuits and hands off to the JavaScript engine if the WebAssembly module cannot load or a gate is outside its set.
• A stabilizer engine for Clifford-only circuits on the Team and Enterprise plans. It checks the circuit against an explicit list of Clifford gates and refuses anything else.

You can leave engine choice on automatic or pick an engine yourself; the picker shows the qubit cap that applies to that engine on your plan.

Routing. On automatic, the IDE uses a state-vector engine whenever the circuit fits. A Clifford-only circuit that is too wide for those engines goes to the stabilizer engine where the plan includes it. A general circuit that is too wide for the state-vector engines is not quietly rerouted to a server: no engine accepts it, and the run does not go ahead. Wider circuits are possible only in the Clifford case, and the plan descriptions say so.

Results. After a state-vector run you get a histogram of outcome probabilities scaled to your chosen shot count, a table of amplitudes with phase and probability, and a Bloch sphere for the qubit you select. The Bloch vector is drawn from that qubit's reduced state, so it is visibly shorter when the qubit is entangled with others. After a stabilizer run you get a sampled measurement histogram, and the IDE states plainly that there is no state vector or Bloch sphere to show for that result. Each result carries a label saying where it ran.

What goes to the server. Running the engines in the browser does not make the app an offline tool. Sign-in and a per-run usage check go through the server, and optional features such as the AI assistant send a summary of the circuit when you invoke them. The IDE also includes a consent step for any run that would need a server-side engine: nothing is uploaded for simulation unless you confirm, and you can decline and keep the circuit local.

Getting circuits in and out. The QASM tab shows the drawn circuit as OpenQASM 2.0 text, lets you download it, and imports a common subset of the language back into the visual editor, listing any statement it could not draw instead of dropping it silently. A transpiler panel generates matching code for Qiskit, PennyLane, CUDA-Q, and OpenQASM 3 to copy into your own project. Circuits can be saved to and loaded from your browser's local storage.

Starting points. A public gallery includes worked examples — a Bell state, a GHZ state, teleportation, a small Grover search, Deutsch–Jozsa, variational ansatz circuits, and a surface-code syndrome round — each of which opens in the editor as a real, runnable circuit.

When a browser simulator is the right tool

Use a browser simulator when you are learning gates and want to see amplitudes change, when you are sketching an algorithm and want to confirm the state before writing framework code, or when you are studying Clifford circuits such as error-correction rounds and care about measurement statistics.

Look elsewhere when you need noise that matches a specific device, general circuits wider than a state vector can hold, or results from real hardware. No simulator of this kind replaces those, and a tool that suggests otherwise is describing its Clifford limit as if it were a general one.

You can see which plan includes which engine on the pricing page, or create an account and start with the free state-vector engine.