Online OpenQASM Simulator: Run a Circuit in the Browser and Read the Counts

What people mean by an online OpenQASM simulator

If you searched for an online OpenQASM simulator, you probably have a circuit as text and want to know what it does without setting up a Python environment first. That is a reasonable thing to want. OpenQASM is the closest thing quantum computing has to a common assembly language: a plain-text file that declares some qubits and classical bits, applies gates to the qubits in order, and measures them.

A small example reads almost like a sentence. Declare two qubits and two classical bits, apply a Hadamard gate to the first qubit, apply a controlled-NOT from the first to the second, then measure both. That is a Bell pair, and it is the usual first circuit because its result is easy to recognise: the two measured bits always agree.

An online simulator takes that text and tells you what you would observe. To use one well, it helps to know what it is computing on your behalf.

What a statevector simulator computes

A quantum circuit on a handful of qubits describes a list of complex numbers called amplitudes, one for every possible bitstring. A statevector simulator keeps that whole list in ordinary computer memory and updates it gate by gate, using nothing more exotic than linear algebra. When it reaches a measurement, it turns the amplitudes into probabilities using the Born rule and draws random samples from them.

Three consequences follow, and each one matters when you read the output:

• It is a classical computation. Nothing quantum happens anywhere. The simulator is a program doing arithmetic. This is simulation, and it should be called that.
• It is ideal. Unless a simulator explicitly adds a noise model, every gate is applied exactly as written. The result is what the circuit means, not what a physical machine would return.
• It does not scale. The list of amplitudes doubles in length with every added qubit. That growth is the reason quantum hardware is interesting in the first place, and it is also the reason every statevector simulator has a hard ceiling on circuit width.

Shots and counts: reading the output

A simulator could simply print the probabilities, and some do. Most also imitate what hardware gives you, which is samples. One run of the circuit ending in measurement is a shot, and it produces one bitstring. Many shots produce a table of counts: each bitstring that appeared, and how often.

For the Bell pair, the counts split roughly evenly between the all-zeros string and the all-ones string, and the two mixed strings do not appear. "Roughly" is the important word. Counts are a sample, so two runs of the same circuit give slightly different tables, and the split is rarely exactly even. More shots narrow that sampling spread; they do not change the underlying distribution.

A practical habit: before trusting a circuit, predict the counts you expect for a tiny input, run it, and compare. If an ideal simulator disagrees with your prediction, the circuit or the prediction is wrong, and it costs nothing to find out which.

Where simulation stops being enough

An ideal simulation answers one question: is this circuit logically correct? It does not answer several others that matter once you move toward a device.

• Noise. Real gates and real measurements have errors. A circuit that produces a clean two-peak histogram in simulation can produce a smeared one on hardware.
• Connectivity and gate set. A simulator lets any qubit interact with any other. Devices do not, and they support a specific set of native gates, so a circuit is rewritten before it runs. The rewritten circuit is usually deeper than the one you wrote.
• Size. Past the simulator's ceiling there is no ideal reference to compare against at all.

This is why depth and two-qubit gate count are worth watching early. They are rough proxies for how much a circuit will suffer on a noisy device, and you can read them straight from the circuit text.

Running OpenQASM in Q-Bridge

Q-Bridge is a web dashboard for writing circuits, running them, and keeping track of the resulting jobs. Here is what the web app does today, stated narrowly.

An editor with a simulator button. The dashboard has a circuit editor with starter snippets. Its "Run in Simulator" action sends your OpenQASM to the Q-Bridge service, which executes it on a statevector simulator and returns measurement counts to the editor's output log. The simulator is ideal: it has no noise model.

Jobs you can come back to. From the jobs page you can submit a circuit as a named job: pick a backend from the list, paste the OpenQASM, choose a shot count, and submit. The job list refreshes as the service pushes status changes, so a job moves from queued to running to completed without you reloading the page. A completed job's page shows the circuit you submitted and a histogram of its counts.

A circuit analyzer. Paste OpenQASM and the analyzer reports gate count, depth, qubit count, a per-gate breakdown, how many gates act on two qubits, how many measurements there are, and which pairs of qubits interact. It recognises both the older qreg style of register declaration and the newer qubit style. It is a deterministic parse of the text that runs in your browser, not a compiler: a custom gate definition counts as a single operation, and classical control is ignored. It does not estimate execution time.

Limits that are stated up front. The simulator has a qubit ceiling enforced by the service, and the Free plan has a lower one. The job form checks your circuit's declared qubits against your plan before submitting and tells you which limit you hit. Current limits are on the pricing page.

An account. The dashboard is behind sign-in. You can create an account on the Free plan.

What about real hardware?

The backend list in Q-Bridge always starts with the built-in simulator, and that is what runs your circuit when you have not supplied provider credentials.

Q-Bridge does not hold hardware provider credentials on your behalf. Submitting to a hardware backend is a bring-your-own-credentials arrangement: you need your own account with the provider, and you enter your keys in the dashboard settings. Those keys are kept in the memory of the browser tab only. They are not written to browser storage, they are attached only to the requests that need them (the backend catalogue, job submission and job result refresh), and reloading the page, closing the tab or logging out drops them. A backend in the catalogue is shown as usable only when the service can reach it with the credentials you supplied.

If you are starting out, none of that is needed. The simulator path works with nothing but an account and a circuit.

A sensible first session

• Start with the Bell pair. Run it in the simulator and check that only the two matching bitstrings appear.
• Change one thing, such as removing the controlled-NOT, and predict the new counts before running.
• Paste the circuit into the analyzer and read its depth and two-qubit gate count. Watch how they change as the circuit grows.
• Submit the same circuit as a named job so you have a record with its histogram to compare later versions against.

That loop of predict, run, compare and measure the circuit's shape is most of what an online OpenQASM simulator is for. It will not tell you how a device behaves, and it does not claim to. It tells you whether your circuit says what you think it says, which is the first thing worth knowing.