Checked against NASA JPL Horizons

Short answer: over 80 planetary positions between 1950 and 2050, Asterwise longitudes differ from NASA JPL Horizons by a median of 0.050 arcseconds, and 79 of 80 agree within half an arcsecond. The raw data and the script to repeat the check are on this page.

For scale: one arcsecond is 1/3600 of a degree. A chart shown to two decimal places of a degree rounds at 36 arcseconds, so every difference on this page is far below what any chart displays. The Moon, the fastest body, moves about 0.55 arcseconds per second of time.

Method

Asterwise side. The tropical longitudes below are what POST /v1/western/natal (the Western astrology API) returns for each instant: the engine at commit 7d68ba3, the build serving production when the page was generated, run with the same Swiss Ephemeris data files. The API returns longitude as an unrounded float; nothing here is rounded before the comparison. Location was set to latitude 0, longitude 0, which does not affect geocentric planetary positions.

Reference side. The Horizons API, observer table, centre 500@399 (geocentre), quantity 31, apparent airless positions, times given as Julian Day UT. That returns the observer-centred ecliptic-of-date longitude, the same quantity the Swiss Ephemeris returns by default. Horizons draws each body from its own JPL solution, listed in the per-body table.

What is not on this page. Horizons has no ayanamsa, so sidereal (Vedic) positions cannot be checked against it directly. Asterwise derives them by subtracting the Lahiri ayanamsa, in the Swiss Ephemeris definition, from the tropical longitude verified here; the ayanamsa is a convention rather than an observable. House cusps and the ascendant are also outside Horizons' scope. Both are covered on the reference-chart page, which compares the full Vedic and Western output against a direct Swiss Ephemeris calculation. Rahu is a mean lunar node, not a body Horizons tabulates, and is omitted.

Updated 28 September 2026. Horizons reads each time as UTC. Until this date Asterwise treated a UTC clock time as Universal Time (UT1), which differs from UTC by up to 0.9 seconds between 1972 and today; that put the Moon up to 0.18 arcseconds off at the 1985 to 2026 instants, where it now agrees within 0.07. The engine now converts UTC to UT1 with leap seconds. With the timing exact, the Sun and the inner planets show the same small offset, about 0.05 arcseconds, at every instant; before, the timing error happened to offset part of it, which is why the overall median moved from 0.046 to 0.050 while the Moon's halved. Earlier figures are in the site's history; this page always shows the latest run.

Per body

The one outlier

All 80 comparisons

Longitudes in degrees along the ecliptic of date, 0 to 360. The difference is Asterwise minus Horizons, in arcseconds.

Reproduce it

The script queries Horizons live, runs the Swiss Ephemeris directly, and, if you set an Asterwise API key, calls the public endpoint so you can confirm the same numbers arrive over HTTP. A free key is enough. The Asterwise and Swiss Ephemeris columns agree to 0.0020 arcseconds, which is floating-point noise; the Horizons column is the independent check. The script converts UTC to UT1 with swe.utc_to_jd, as the API does.

pip install pyswisseph requests
curl -O https://asterwise.com/public/accuracy/compare.py
SE_EPHE_PATH=/path/to/swisseph/ephe ASTERWISE_API_KEY=aw_... python3 compare.py

The Swiss Ephemeris data files are not bundled with pyswisseph; download sepl_18.se1, semo_18.se1 and sepl_24.se1 from the ephe directory of the Swiss Ephemeris repository (the location astro.com's own download page points to) and point SE_EPHE_PATH at them. Without them the library falls back to its built-in Moshier ephemeris, which is less precise than the files Asterwise runs on, and the Swiss Ephemeris column will drift from this page.

Questions about the check

How accurate is the Swiss Ephemeris compared with NASA JPL Horizons?

Across 80 geocentric ecliptic longitudes (10 bodies at 8 instants from 1950 to 2050), Asterwise output built on the Swiss Ephemeris differed from JPL Horizons by a median of 0.050 arcseconds, with a 95th percentile of 0.231 arcseconds. 79 of 80 positions agreed within half an arcsecond. One arcsecond is 1/3600 of a degree, far below the two decimal places most charts display.

What exactly was compared?

Apparent geocentric ecliptic-of-date longitudes returned by POST /v1/western/natal (tropical) against the JPL Horizons observer table for centre 500@399, quantity 31, at eight instants between 1950 and 2050. Location does not affect geocentric planetary positions. The engine commit was 7d68ba3, the build serving production when the page was generated on 28 September 2026.

What is the largest difference and why?

2.929 arcseconds, for the Moon at the 2050 instant, the last in the range. The likely cause is that the two systems extrapolate delta-T (the offset between terrestrial and universal time) differently that far ahead; this has not been confirmed with JPL. 79 of the 80 positions agree within half an arcsecond.

Can I reproduce the check myself?

Yes. The comparison script (compare.py) and the raw comparison data (JSON) are published on this page. The script queries Horizons live, runs the Swiss Ephemeris directly and, with an Asterwise API key, calls the public endpoint so the same numbers can be confirmed over HTTP.

Downloads: raw comparison data (JSON) · compare.py. The Horizons responses are fetched live, so your run can differ from this page by hundredths of an arcsecond if JPL revises an ephemeris.