About this map

What it is, where the numbers come from, and how they're calculated.

This is a hobby project — I wanted to see every total solar eclipse through 2055 overlaid on one map, click anywhere in a path, and get a real answer for "when does totality start here, how long does it last, will terrain block it, and what's the weather usually like." I am not an eclipse expert, an astronomer, or a geodesist. I built this with Claude Code (Anthropic's AI coding assistant) — it wrote the actual implementation; I directed it, reviewed what it produced, and used the whole project as a way to learn the real astronomy and geometry behind it as I went, rather than writing this orbital-mechanics- adjacent math from scratch myself. Be clear-eyed about what that means: this is, in plain terms, AI-generated output from someone who isn't qualified to independently catch every mistake in it. It hasn't been reviewed by an astronomer, a geodesist, or anyone else with the domain background to actually vet it. If you're making a real decision — where to stand, whether to book travel, what to tell other people — use Xavier Jubier's map, not this one. Use this one for curiosity, and to check my math against it, not instead of it.

So this page exists for one reason: so you can check the work, knowing that up front. Every section below says exactly what data this map pulls from, what calculation runs on it, and how confident you should be in the result. If something looks wrong, I'd genuinely like to know — that's the point of writing it all down like this, and it matters more, not less, given how it was built.

Before anything else: if you want the definitive eclipse map — the one built by someone who actually does this professionally, refined over decades, and trusted by the eclipse- chasing community as the reference tool — that's Xavier Jubier's interactive eclipse maps. I built this to learn how the underlying math actually works and have a version of my own to poke at and extend, not because anything here is meant to compete with his. I'll also admit a more practical reason: I noticed his site was sometimes temporarily unreachable, and wanted something of my own I could still pull up and play with when that happened — not a replacement for it, just a backup for the moments it's down. Specific places his is more accurate than this one are called out in the sections below, not just this notice.

Path shape & totality duration

Every eclipse's path geometry — the northern limit, southern limit, center line, and timing/duration along it — comes from NASA GSFC's published Espenak/Meeus eclipse predictions (the same lineage as Jubier's own Five Millennium Canon of Solar Eclipses data). Each eclipse's exact source page is recorded in its own data file. That published table only samples the path every ~2 minutes, though — for a specific point you actually click, this map estimates local circumstances one of three ways, tried in order of precision:

A dense, minute-by-minute element table — the most precise method this map uses, accurate to roughly 1–3 seconds. NASA's own published elements aren't sampled this tightly (they're a single polynomial fit spanning several hours, tier 2 below), so there's no existing published table at this resolution to simply download. Instead, this queries JPL Horizons — NASA/JPL's own live ephemeris service, the same underlying planetary data (JPL's DE441 ephemeris) that all of this ultimately traces back to — directly, for the real geocentric Sun/Moon position every minute across the eclipse, and computes the standard textbook Besselian-element construction from those raw positions itself (shadow axis as the Sun-to-Moon vector, projected onto the fundamental plane, with the usual umbral/penumbral cone-angle formulas for l1/l2) — not a new or invented method, the same formulas NASA's own elements are built from, just evaluated at 1-minute steps instead of fit as one polynomial across hours.

How this was checked: during development, this method's own output was compared directly against NASA's own published elements for the 1994 Nov 3 eclipse and matched to 5–6 decimal places. Separately, the local-circumstance times it produces were checked against Xavier Jubier's own published numbers for the Aug 2, 2027 eclipse and matched to about 1 second at a test point in Tarifa, Spain. Both are real, specific comparisons against independent published numbers — not just an internal self-consistency check — but two spot checks is still two spot checks, not a systematic validation across every eclipse this map covers.
NASA's own published Besselian elements, solved directly, when the dense table above isn't available for a click. Accurate to a fraction of a second on duration, but the underlying published elements are a lossy polynomial fit, so absolute timing can be off by roughly 20–30 seconds — worse for a not-yet-happened eclipse specifically, since the Earth-rotation correction (ΔT) they depend on is a forecast that different NASA sources don't even fully agree on yet.
Simple interpolation of the ~2-minute-sampled path table itself, as a last resort — duration is scaled down linearly from center line to path edge, which isn't exactly how it really falls off. Precision here is more like seconds to low tens of seconds.

Where Jubier's map is more accurate than this one His northern and southern path limit lines themselves are corrected for the Moon's actual lunar limb profile — real lunar mountains and valleys, not a smooth sphere — by finding where the limb-corrected duration hits exactly zero. That gets his path edges to roughly 1–2 km accuracy. This map's path edges come straight from NASA's own published table, which assumes a smooth lunar limb. Real lunar terrain only comes into this map's own calculations for the Baily's-beads diagrams below, at a point you've already clicked — never to redraw the umbra boundary itself. Near the very edge of a path, trust Jubier's line over this one about whether you're in or out of totality at all.

Baily's beads diagrams

For any click resolved by the dense-element tier above, the Contact Images panel draws a rough "what the diamond ring might look like" diagram for 2nd and 3rd contact. This is directly inspired by real published research on this exact question — Xavier Jubier's own work with Jay Pasachoff and Ernest Wright on lunar limb profiles at total eclipses is the real, professionally-rigorous version of this idea. What's here is a much simpler amateur attempt at the same question, combining two effects:

Smooth-sphere geometry. Even for a perfectly round Moon, only the exact instant of 2nd/3rd contact has zero timing offset — a few seconds either side, the exposed sliver of Sun already spans a wide range of angles around the limb, because the Sun and Moon's apparent sizes are so close. This is plain two-circle overlap geometry.
Real lunar terrain. For angles around that window, this maps onto an actual point on the Moon's surface (using that instant's real libration) and looks up its real elevation from NASA/USGS's public LOLA lunar terrain data, precomputed per eclipse rather than fetched live. A valley in that terrain lets light linger a little longer — a bead.

The angle-to-lunar-surface-point mapping was worked out from scratch (not copied from an existing reference I could just trust), so before relying on it I checked it against an independent, well-established formula and confirmed the two agree. Still: this is a simplified, linear estimate near each contact instant, not a full simulation of the actual light curve — it tells you roughly where and how many beads to expect, not a frame-by-frame prediction.

Terrain / horizon check

Clicking a path also draws a small chart comparing the Sun's altitude at that moment against the real ground elevation between you and the horizon in the Sun's direction, out to 60 km — if the terrain line ever rises above the Sun's altitude line, something between you and the Sun would block totality from that exact spot.

Ground elevation comes from the public Copernicus DEM GLO-30 dataset (30m resolution, free for commercial use with attribution) or, depending on which map mode is active, Google's Elevation API. Both are real measured elevation data, not estimated.

What this check does not account for: buildings, trees, or anything else not in a bare-earth elevation model; and it checks one straight line at one instant, not the Sun's actual slow movement across the sky over the full length of totality.

Historical weather

The Weather panel shows typical cloud cover, rain frequency, and temperature for that spot around that calendar date — this is climatology, not a forecast for the actual eclipse. It comes from NASA's POWER project (satellite and reanalysis-derived daily weather data, with real modeled coverage even over open ocean), averaged across every year from 1981–2020 within a week of the eclipse's actual calendar date. It tells you what that place is usually like in early August (or whenever), not what it will actually be like on eclipse day — treat it as "should I even consider this location," not a weather report.

Everything above is implemented in plain JavaScript with no framework and no build step — the calculations are ordinary, inspectable math, not a black box. If you find an error in any of it, that's useful information, not an inconvenience — please say so.

Again: for the map you should actually rely on for eclipse planning, use Xavier Jubier's interactive eclipse maps.