Surface Code Logical Error Rate Calculator
Introduction to surface-code logical error estimates
Surface-code logical error estimates are most useful when you want to know how a noisy physical device turns into a more reliable logical qubit. The surface code spreads one logical qubit across a two-dimensional patch of many physical qubits, then uses repeated stabilizer measurements to spot the local footprints of trouble. A decoder tries to infer which physical errors probably occurred from those measurements. The central planning question is not whether the code can suppress errors in principle, but how much suppression you get for a given physical error rate and how many qubits you must spend to buy it.
This calculator turns that surface-code tradeoff into a quick planning estimate. If your physical error rate p sits below the threshold pth, increasing the code distance d usually drives the logical error rate down very rapidly. That is the useful regime for architecture sketches: more distance buys stronger suppression. If the hardware is near or above threshold, however, the same extra qubits may stop helping in a meaningful way, so a simple distance estimate can become overly optimistic. The tool therefore combines a logical-error estimate, a threshold check, a rough patch-size rule, and a target-driven distance suggestion in one place.
Because this is a compact back-of-the-envelope model, it is best treated as a first-pass sizing aid for design reviews, roadmap discussions, and “what if we improve p by another order of magnitude?” conversations. It is not a substitute for a full circuit-level simulation that includes the exact decoder, syndrome-extraction schedule, leakage behavior, correlated faults, and calibration details of a specific machine. Even so, the simplified estimate is valuable because it reveals the main shape of the surface-code tradeoff: moving farther below threshold is powerful, distance helps in discrete steps, and qubit overhead grows quickly.
How to use this surface-code calculator
To use the surface-code calculator, start with the physical error rate p you want to model. That number should match the way you interpret the noise in your own planning notes, whether you think about it as a per-round effective error probability or as a compact summary of the dominant fault processes. Next enter the code distance d, which controls the size of the logical patch. Then choose a threshold pth that matches the decoder and noise model you have in mind. Finally, enter a target logical error rate if you want the calculator to suggest a distance that could meet that goal.
- Enter physical error rate p as a decimal value such as 0.001 for 10−3.
- Enter code distance d as a positive integer. Odd values are common in planar surface-code layouts.
- Enter threshold pth for the decoder and noise assumptions you are using.
- Enter a target logical error rate if you want a rough sizing recommendation for the surface code.
- Click Compute Surface-Code Estimate to update the result panel.
When you read the output, think of it as a design estimate rather than a certification result. The logical-error value tells you the approximate failure probability per effective round under the empirical model used here. The physical-qubit count is a rough patch-level estimate, not a full machine-wide budget. The recommended distance is most meaningful only in the below-threshold regime, because once p approaches or exceeds pth, the simple scaling law stops being a dependable guide.
Surface-code outputs this calculator computes
The surface-code outputs on this page are meant to answer the questions people usually ask first during early resource planning. The calculator returns four practical planning numbers. First, it estimates the logical error rate per round or effective cycle. Second, it checks whether your physical error rate is below the assumed threshold. Third, it uses a common rule of thumb to estimate how many physical qubits one planar logical patch may require. Fourth, it inverts the same empirical scaling law to suggest a code distance that could meet a target logical error rate, assuming you are safely below threshold.
- Estimated logical error rate per round, based on the common empirical surface-code scaling used on this page.
- Below-threshold check showing whether the entered physical error rate p is lower than the assumed threshold pth.
- Rough qubit overhead for a planar patch, using the rule of thumb n ≈ 2d2.
- Estimated distance required to meet a target logical error rate, when the model is operating in its intended below-threshold regime.
Surface-code symbols and definitions
The symbols below appear throughout the surface-code estimate. Keeping them straight helps prevent one of the most common planning mistakes in quantum error correction, which is mixing up physical noise numbers, logical failure rates, and code geometry.
| Symbol | Meaning | Typical range or note |
|---|---|---|
| p | Physical error probability for the noise quantity you are modeling | Often 10−4 to 10−2 in projections; the below-threshold estimate only makes sense if it is less than pth |
| pth | Threshold physical error rate for the assumed code, decoder, circuit, and noise model | A common ballpark is around 0.5% to 1%, but real values vary |
| d | Code distance, or the minimum length of a nontrivial logical operator | Usually a positive integer, often odd in standard planar layouts |
| pL | Logical error rate per effective round | Falls rapidly with larger d when p is below threshold |
| n | Approximate physical qubit count for one planar logical qubit | Estimated here as n ≈ 2d2, which is deliberately rough |
Surface-code formulas used here
The surface-code formula used on this page is a widely used empirical approximation for the planar logical error rate in the below-threshold regime. The exact constants are not universal, but this form captures the basic intuition that the logical failure rate falls very quickly with distance when the physical error rate is comfortably smaller than the threshold.
The ratio p/pth tells you how close the hardware is to threshold. The exponent ( d + 1 ) / 2 means that each increase in distance adds another power of that ratio, which is why the suppression can feel almost exponential in practice. The prefactor 0.1 is simply a convenient fit parameter from a particular family of simulations and should not be treated as a fundamental constant of nature.
For qubit overhead in a surface-code patch, the calculator uses a familiar rule of thumb:
n ≈ 2d2
If you provide a target logical error rate pL,target, the same scaling law can be inverted to estimate a distance requirement. In plain language, the target asks how many extra distance steps you need before the empirical suppression law pushes the logical failure rate low enough for your application.
( d + 1 ) / 2 ≈ log( pL,target / 0.1 ) / log( p / pth )
After solving, the result is rounded up to an integer distance, and many practitioners then choose the next odd distance because that is common in planar layouts. The calculator follows that spirit by returning a practical sizing recommendation rather than a fractional distance that no hardware layout can use directly.
Interpreting the surface-code results
If the result says you are below threshold, the surface-code model is in the regime where increasing distance should make logical faults rarer. In that regime, even a modest improvement in physical error rate can produce large savings in required distance and therefore large savings in physical qubits. This is why threshold margin matters so much: once the hardware moves farther below threshold, the economics of fault tolerance improve very quickly.
If the result says you are above threshold, be cautious. The calculator can still evaluate the empirical expression, but the qualitative promise of the surface code is no longer guaranteed by that number. Near or above threshold, increasing distance may stop helping, or help only weakly, because fresh errors arrive faster than the code can suppress the dangerous long chains that cause logical faults.
The physical qubits output is intentionally conservative in wording. A single planar patch may fit the rough estimate n ≈ 2d2, but real machines usually need routing space, spare ancillas, lattice-surgery work areas, magic-state support, leakage handling, and control margins that are not captured by a one-line formula. Use the estimate to compare distances, not to finalize a full architecture budget.
Worked example: a below-threshold surface-code patch
A concrete surface-code worked example makes the scaling easier to interpret. Suppose your hardware model gives a physical error rate of p = 1×10−3, your assumed threshold is pth = 1×10−2, and you are considering a distance d = 5 patch. The key ratio is p / pth = 0.1, which means the physical noise is one tenth of threshold. The exponent is (5 + 1) / 2 = 3, so the logical error estimate becomes:
pL ≈ 0.1 × (0.1)3 = 0.1 × 0.001 = 1×10−4
Now consider the overhead. Using n ≈ 2d2, the patch would require about 2 × 25 = 50 physical qubits. That number is not the whole computer, but it is a reasonable first estimate for one logical patch under this simplified model. Already you can see the central surface-code tradeoff: a modest logical error estimate requires a nontrivial patch of physical hardware.
If your application instead asks for a target logical error rate of 1×10−6 at the same p and pth, then you solve the inverted relation for distance. In this particular example, the estimate lands around d = 9. The jump from distance 5 to distance 9 does not sound enormous at first, but the corresponding patch-level qubit count rises from roughly 50 to roughly 162. That is exactly why planning with both reliability and overhead in view matters.
Surface-code distance comparison table
The table below shows how a few small steps in code distance can change both suppression and overhead in the surface code. For a fixed ratio p/pth below 1, each distance increase adds another power of that ratio, so the reliability gain can be dramatic even while the qubit cost climbs rapidly.
| Distance d | Exponent (d + 1) / 2 | Estimated qubits n ≈ 2d² | Scaling intuition for fixed p/pth < 1 |
|---|---|---|---|
| 5 | 3 | 50 | A compact baseline distance for rough examples |
| 7 | 4 | 98 | One more power of the below-threshold ratio suppresses logical error further |
| 9 | 5 | 162 | Often a significant step toward very low logical error targets |
| 11 | 6 | 242 | Higher reliability, but the patch cost becomes much more substantial |
Assumptions and limitations of the surface-code estimate
This page uses an empirical surface-code model, not a theorem that is valid for every decoder and every noise channel. The fit constant, the effective exponent, and even the best functional form can move around when you change the syndrome-extraction circuit, the decoder, the balance of gate and measurement errors, or the amount of correlated noise. Treat the number as a disciplined estimate rather than a promise.
It also compresses many kinds of hardware noise into a single scalar p. Real systems usually report separate values for one-qubit gates, two-qubit gates, measurement, idling, crosstalk, and leakage. Folding all of that into one parameter is useful for intuition, but it hides structure that can matter a great deal for a true architecture study. Likewise, the logical error rate may be quoted per round, per cycle, per logical gate, or per unit time; the calculator does not convert among those interpretations for you.
Finally, the overhead estimate is intentionally light-touch. Rotated patches, unrotated patches, lattice-surgery boundaries, spacing rules, injected-state factories, and layout choices can all shift the real qubit requirement. Even so, a compact estimate is worth having because it makes the basic scaling visible. The surface code is powerful precisely because it converts better physical qubits into sharply better logical qubits, but the price is geometric growth in hardware size. That is the trade this calculator is built to highlight.
Use the result as a fast starting point, then validate any serious hardware decision with decoder-specific simulations and architecture-aware resource estimates.
Mini-game: Surface-code Chain Breaker
This optional mini-game turns the surface-code logical-error problem into something you can feel. Red cells represent physical errors spreading across a logical patch. If they connect one boundary to the opposite boundary, a logical fault occurs. Your job is to act like a fast decoder: click or tap unstable cells to break the chain before it spans the patch. The current values of distance d and the ratio p / pth seed the starting difficulty, so a larger patch gives you more room while a ratio closer to threshold creates a busier, riskier board.
Educational takeaway: in the real surface code, a logical failure appears when a chain of physical errors becomes long enough to cross the patch. Increasing the code distance makes that path longer, while a higher physical-to-threshold error ratio makes dangerous chains appear more often.