Swiss Ephemeris vs. JPL DE440: Which One Should Your App Use?

Swiss Ephemeris and JPL DE440 are not rival data sources — one is compressed from the other. Here is how licensing, accuracy, and setup cost actually compare.

comparisonswiss-ephemerisjpl-de440ephemerisdevelopers

Ask a developer building astrology software which ephemeris to use, and most will say Swiss Ephemeris without thinking twice. It has been the default for twenty-five years — the C library behind Astro.com, most desktop astrology software ever shipped, and a long tail of hobbyist projects since the 1990s.

That default is usually right. But "usually" is not "always," and two separate questions get conflated constantly: is it accurate, and is it the right fit for what you're building. Swiss Ephemeris and NASA JPL's DE440 kernel are not two competing sources of truth. One of them is built from the other. Understanding that relationship — and where a hosted API changes the calculus — is what actually decides which one your app should use.

This is not a hit piece. Plenty of serious software should keep using Swiss Ephemeris. Here is the honest version of how the two compare.

Where Swiss Ephemeris Data Actually Comes From

Swiss Ephemeris, maintained by Astrodienst AG, is not an independent astronomical calculation. It is a compressed, redistributable repackaging of NASA JPL's own ephemeris data. As of the current library release, that source is JPL's DE441 — the long-timespan sibling of DE440 — reduced into Astrodienst's own .se1 file format at roughly 97 MB, small enough to ship inside a desktop installer instead of the multi-gigabyte JPL kernel it is derived from.

Which means the accuracy question has a specific answer: swisseph's precision is bounded by how faithfully it reproduces the JPL numbers it started from, not by an independent measurement of the sky. JPL is the upstream source of truth for both Swiss Ephemeris and OpenEphemeris. What differs between them is not the astronomy underneath — it's how each product delivers it.

Swiss Ephemeris Accuracy: What the Claims Actually Mean

Astrodienst's own documentation states that Swiss Ephemeris reproduces its parent JPL ephemeris to within roughly 0.001 arcseconds — a tolerance far below anything a birth chart, transit forecast, or synastry reading is sensitive to. OpenEphemeris computes directly against the DE440 kernel, at sub-arcsecond precision, without an intermediate compression pass.

For the things an astrology app actually depends on — which sign a planet is in, which house cusp a placement falls near, whether two planets are in aspect — the two agree. Neither the compression step in Swiss Ephemeris nor the direct kernel read in OpenEphemeris introduces error anywhere near large enough to move a placement across a sign boundary or change an aspect's orb category. If you are choosing between them on the theory that one produces a "more correct" chart, that is not actually the deciding variable. We are not publishing a position-by-position diff here, because we do not have one we would stand behind as a general claim — running both against a case that matters to your app is the only honest way to verify it for your own use.

Where the two genuinely diverge is everything downstream of the raw position: how you get it, what you are allowed to do with it, and what happens as your traffic scales.

A stack of machinist's gauge blocks beside the single master block they all derive from — different tools, one shared standard underneath

The Swiss Ephemeris License: AGPL or a Paid Contract

This is usually the part that actually decides the question, and it gets skipped in most "which ephemeris" writeups.

Swiss Ephemeris ships under a dual license. The free option is the AGPL v3, and the clause that matters for a web developer is Section 13, the network clause. Unlike the plain GPL, which only triggers when you distribute binaries, the AGPL treats network access as distribution — which means if a user interacts with your swisseph-linked application over a network, meaning any hosted SaaS, any web app, any API you run, you are obligated to offer them the complete corresponding source of that application, not just the ephemeris library. Running it server-side does not exempt you. That is exactly the situation the clause was written for.

The alternative is Astrodienst's professional license: a one-time fee, unlimited volume, a long fixed term, no royalties, no per-chart cost. For a team that is happy to self-host, that is a genuinely good deal — arguably some of the cheapest unlimited compute available anywhere. But know what you are signing: it is a paper contract with a Swiss company, support runs through a community mailing list, there is no warranty of calculation correctness, and you cannot reference Astrodienst in your marketing without written permission.

A hosted API sidesteps the question a different way entirely. You are buying query access, not linking source code — no AGPL exposure to reason about, no license contract to file away. You pay for computation, metered in credits, not for permission to redistribute a library.

What It Actually Costs to Integrate

Licensing decides whether you are allowed to use Swiss Ephemeris. Integration cost decides how much engineering time it costs you once you have.

Swiss Ephemeris is a C library. To use it, you compile it — or reach for a language wrapper, such as Python's pyswisseph, or bindings for Java, PHP, Perl, Node, or R — bundle the ephemeris data files it reads from disk at runtime, and keep all of that consistent across every environment you deploy to: local dev, CI, staging, production, and however many regions you run in. None of this is exotic engineering. Thousands of production astrology apps do exactly this. But it is engineering, and someone on your team owns the build, the data file versioning, and what happens when a new JPL release ships and the .se1 files need updating.

A REST call is a different shape of cost. A single request with a datetime, latitude, and longitude returns structured JSON — sign, house, aspect grid, dignities — over HTTPS, with no binary to compile and no data files to ship. For an AI agent, the same computation is available as an MCP tool call, which means a Claude-based application can request a chart mid-conversation without your team maintaining any calculation infrastructure at all. The trade runs in the expected direction: you give up the zero-latency, fully-offline execution of a linked C library, and in exchange you stop owning that infrastructure.

Coverage: Time Range and Body Catalog

This is the category where Swiss Ephemeris is simply ahead, and the honest comparison says so plainly rather than burying it in a footnote.

Swiss Ephemeris covers roughly 13,201 BCE to 17,191 CE — about 30,000 years — and includes more than 385,000 numbered asteroids, hypothetical and Uranian points, and an extensive fixed-star catalog. OpenEphemeris, computed directly from the JPL DE440 kernel, covers 1550 to 2650 CE — a little over eleven centuries — with a curated set of the bodies most working charts actually use, plus the major Ptolemaic fixed stars, rather than the full astronomical inventory.

If your app needs a chart for 3000 BCE, or a client wants an obscure numbered asteroid cross-referenced against a hypothetical point, Swiss Ephemeris is the only one of the two that can do it today. That is a real limitation, not a rounding error, and it belongs in this comparison without softening.

When Self-Hosting Swiss Ephemeris Is the Right Call

None of the above is an argument that everyone should switch to a hosted API. Self-hosting Swiss Ephemeris is the right call in a few specific, common situations:

You're building offline or desktop software. A locally linked C library has no network dependency at all. An API cannot compete with that for an app that has to work on a plane with no signal.
You need dates or bodies outside DE440's range. Ancient-history research tools, or anything that touches the deep numbered-asteroid catalog, needs coverage only Swiss Ephemeris currently provides.
You've already paid for the professional license. If your team holds the license and has already built the integration, the marginal cost of every additional chart is zero. No API pricing beats free.
You're comfortable owning the infrastructure. Some teams want direct control over the calculation layer and don't mind maintaining it. That control is worth something real, and it's a legitimate reason on its own.

The honest reason to reach for a hosted API instead is not that Swiss Ephemeris is inaccurate or badly built — it demonstrably isn't. It's that you would rather not compile a C library, manage data files across five environments, and reason through AGPL Section 13, and would rather get back a REST call and structured JSON, with someone else responsible for keeping the calculation engine correct and current. That's the actual trade you are making, in either direction.

Neither of these is the "real" ephemeris with the other one a knockoff. Swiss Ephemeris and OpenEphemeris both trace back to the same NASA JPL source data. The genuine disagreement between them is about license terms, infrastructure ownership, and how far back in time your app needs to reach — not about whose planets are more real. Once you know which of those actually matters for what you're building, the choice mostly makes itself.

Want the fuller picture of what an ephemeris is before you compare two of them? Start with What Is an Ephemeris?. And if a hosted, DE440-direct API is the shape you want, the docs cover the full endpoint surface — with a free Explorer tier, 150 credits to start, one-time, no credit card, enough to pull a chart and see for yourself.