What Swiss Ephemeris is, and why it matters

Swiss Ephemeris · maintained by Astrodienst since 1997 · this build: version 2.10.03 · embedded data covers about 1800-2400 · J2000 Sun longitude 280.368166°, matches the reference exactly

01What the name actually refers to

Swiss Ephemeris is not a feature or a marketing phrase. It is a specific piece of software that computes where a planet actually sat in the sky at a given moment, built from the same class of precise numerical models professional astronomy uses rather than from the simplified formulas older almanacs relied on — maintained by Astrodienst since its first release in September 1997. In the three decades since, it has become the calculation the wider astrology-software industry treats as the reference: not because Astrodienst positioned it that way, but because the alternative, for most of that industry, would be building and maintaining an equivalent planetary theory from scratch, which is a bigger undertaking than most calculator sites or apps have ever taken on.

That history matters for what this piece can honestly claim and what it cannot. Reading planetary positions from that same underlying data is table stakes for a chart that wants to call itself accurate — parity with the standard the field already agrees on, not a discovery of a better one. Nothing below claims otherwise.

02What actually runs underneath a chart

The specific implementation this product runs is a WebAssembly build of that library, chosen over the alternative of a native binding for a plain, checkable reason rather than a preference: a native binding has to be compiled separately for whatever platform it eventually runs on, and a serverless function's platform is not something this product controls or guarantees will stay fixed. WebAssembly sidesteps that entirely — it runs identically whether the request lands in a serverless function, a browser, or a future mobile build, with no compile step in between and no risk of a binary built for the wrong target silently failing at the one moment nobody is watching. The engine's own interface to the ephemeris is written as a narrow, swappable boundary specifically so that choice can change later without touching anything else: if the delivery mechanism ever needs to move to a native binding, that is a change to one file, not a rewrite of the calculation itself.

Choosing WebAssembly over a native binding is a delivery decision, not an accuracy one, and it is worth being precise about that distinction: the two are different ways of running the identical underlying library against the identical data, and the wrapper's own methods have been checked against the native implementation directly rather than assumed to match because they share a name. The version currently running is stated once, in the engine's own constants rather than typed into a page by hand, and a dedicated test asks the running module what version it reports and fails the build if that answer disagrees with the stated one — so the version number on a page showing it is a live fact about the code actually executing, not a string that can quietly go stale the next time the dependency updates.

03Two different clocks, and why mixing them breaks a chart

Underneath the single word "ephemeris" sit two genuinely different timescales, and keeping them apart is the single most consequential detail in the whole calculation. A planet's position is computed in Ephemeris Time — a uniform timescale the underlying tables are built on — while a chart's houses and angles are computed in Universal Time, because they depend on the Earth's actual, slightly irregular rotation in a way an orbital position does not. The gap between the two, called ΔT, is not a fixed number added or subtracted by convention; it comes from the ephemeris's own table, which is updated as the Earth's rotation is measured more precisely over time. Getting from a birth record to either timescale means resolving the local clock reading through whatever time zone actually applied at that place on that date — daylight-saving transitions included — before either calculation can run at all.

This is also the honest answer to why two tools that both say "Swiss Ephemeris" can still disagree on the same chart. The underlying position data is shared, and a native build of the library and a WebAssembly build of the same library have been checked against each other and agree, so the raw planetary longitudes are not where a disagreement is likely to come from. What differs between tools is everything built on top of that shared data: which ΔT table is current, how carefully the historical time zone was resolved for an older or less common birthplace, whether the ET/UT split was kept straight at every step or quietly collapsed into one timescale somewhere in the pipeline, and which house system or orb convention was applied afterward. Two calculators reading the identical ephemeris can still produce visibly different house cusps if one of them is careless about any of that — not because the ephemeris disagreed with itself, but because everything after it did.

04Why the fuller data, not the lighter option

Swiss Ephemeris can run in more than one mode, and the lighter one — a purely analytical approximation that needs no data file at all — was considered and set aside for a specific, checkable reason: it cannot compute Chiron or the smaller asteroids this product shows on a chart, because those bodies' orbits are not the kind a closed-form approximation handles well. Getting them at all means reading from the fuller, file-based ephemeris instead, which is the version this product actually runs.

The data embedded in that build is not the library's entire multi-thousand-year catalogue — that full range covers eight thousand years, which as a data file runs to roughly a hundred megabytes and would make the module far larger than it needs to be for a birth-chart product. What is embedded instead is a narrower slice, running from around 1800 to 2400, a fraction of that size, which comfortably covers every plausible birth this product will ever be asked to chart while keeping the module small enough to ship inside a serverless function without a separate download step. A chart for a birth outside that roughly six-hundred-year window is a real, current boundary rather than a hidden one, worth stating for exactly the same reason every other limit in this product gets stated rather than smoothed over.

05How the numbers were actually checked

Before any of this ran in production, the specific build in use was checked against the reference implementation directly rather than trusted on reputation. A single, independently verifiable figure anchors the check: the Sun's ecliptic longitude at the J2000.0 epoch, a moment precise enough that its correct value is published and agreed on, computed by this build to 280.368166 degrees — matching the reference figure exactly rather than approximately. All twenty of the bodies this product can place on a chart computed successfully in the same pass, and the majority of the wrapper's own methods — 86 of the 104 it exposes — have been checked numerically against the underlying library's native implementation rather than assumed correct because they share a data file. That is the actual meaning of "verified" here: a specific number, checked against a specific published reference, not a general assurance offered without one.

06What it is not

This is not a claim to compute planetary positions more accurately than the ephemeris itself, and it is not a claim to be more accurate than any other tool reading from the same tables. The underlying planetary theory is identical wherever it is read from; a chart computed here for a given birth should agree with a chart computed anywhere else that reads the same data carefully, to whatever precision both tools carry the calculation out to. Accuracy, stated honestly, is parity with a shared standard the wider field has already settled on — not a discovery this product made on its own, and not a contest with anyone else reading from the same source.

It is also not a claim that "Swiss Ephemeris" by itself is a differentiator worth advertising on its own terms. Reading from an accurate ephemeris is the floor a chart needs to clear to be worth trusting at all, not a ceiling that separates a serious tool from a careless one — plenty of tools read the same data and still produce a worse chart, for every reason worked through above: a stale ΔT table, a mishandled time zone, an ET/UT split collapsed somewhere in the pipeline. The ephemeris is necessary. It has never been sufficient on its own.

Stating the version, the timescale split and the verification numbers this plainly is not a decoration on top of that claim — it is the claim, made checkable. A reader with no reason to take any of this on trust can compare the stated J2000.0 figure against a published reference themselves, can compare a computed chart against another tool reading the same data, and can watch for the version stamp changing the next time the underlying library updates. None of that requires believing the product; all of it can be verified independently of it.

07Where you see it in your own chart

The exact engine version, the ET/UT split, and the birth-time confidence rating a chart was computed under are stated on the methodology page rather than left implicit, and they are read from the same code that runs the calculation rather than typed in separately — which is the only way a claim like this stays checkable rather than becoming one more unverifiable line of marketing copy.

→ Read the full methodology · Compute your chart

08Related reading

What this product claims, and what it does not covers the same accuracy boundary from the positioning side — parity, not superiority — in full. House systems covers the other half of the ET/UT split this piece leans on: houses computed in Universal Time, from the same birth data the position calculation resolves separately. Chiron is the clearest example of what the fuller, file-based ephemeris makes possible that the lighter alternative could not.

Updated 2026-05-06.