How Kundli.site Calculates Your Chart: Full Methodology Transparency

Direct answer: kundli.site computes your chart in six auditable steps: birth time → UTC (with timezone/DST handling), planetary positions from a Swiss-Ephemeris-parity engine, sidereal conversion with Lahiri ayanamsa, whole-sign houses from sidereal time, Vimshottari dasha from Moon nakshatra, and 16 vargas plus yogas. Every step is published; the engine is verified to ≤0.005° against the Swiss Ephemeris.

Most kundli sites are black boxes: birth details go in, a chart comes out, and you're asked to trust the middle. This page opens the box completely. Every step below is what our engine actually does, in order — with the standards, the math, and the verification. If any step looks wrong to you, we'd genuinely like to hear about it: falsifiable claims are the point.

The pipeline at a glance

The pipeline: six steps, zero magic

Step 1 — Birth time → UTC (timezone + DST done right)

Your local birth time is converted to Universal Time, because all astronomy runs on UTC.

• Timezone lookup by birthplace (city-level, not country-level)
• Historical DST rules applied for the birth date — DST rules change by year and jurisdiction, so we use date-aware tz data, not a fixed offset
• Pre-standardization offsets handled where applicable

Why this step is first: a one-hour error here shifts the ascendant ~15° — an entire sign. Timezone handling is the most common real-world source of wrong charts across the industry, so it's where our testing is heaviest. Invalid or ambiguous inputs are rejected rather than silently guessed.

Step 2 — Planetary positions (Swiss-Ephemeris parity)

Positions for the Sun, Moon, Mars, Mercury, Jupiter, Venus, Saturn, plus Rahu/Ketu (lunar nodes), are computed from our homegrown engine, benchmarked to Swiss Ephemeris parity:

• Reference: Swiss Ephemeris (NASA JPL DE431/DE441 integrations, ~0.001 arcsecond native precision)
• Our tolerance: ≤0.005° (18 arcseconds) across the verification set
• Nodes: mean lunar nodes with the standard Vedic convention; Ketu placed exactly opposite Rahu

18 arcseconds is roughly 1/650th of a nakshatra pada (3°20′, i.e. 12,000 arcseconds). No Vedic technique operates anywhere near that scale — the tolerance is engineering margin, not astrological relevance.

Step 3 — Sidereal conversion (Lahiri ayanamsa)

Vedic astrology uses the sidereal zodiac: tropical longitude minus the ayanamsa.

• Ayanamsa: Lahiri (Chitrapaksha) — the Indian Calendar Reform Committee standard, the default of mainstream Indian practice
• Computed for the exact birth moment (ayanamsa drifts ~50.3″/year, so it's date-specific, not a constant)
• For reference 2026 values: Lahiri ≈ 24°13′; KP ≈ 24°08′; Raman ≈ 22°47′; Yukteshwar ≈ 21°20′ (verify against a published table) (full table)

Step 4 — Ascendant and houses (whole-sign, classical default)

• Lagna from local sidereal time + birth latitude
• House system: whole-sign — the classical Parashari default: the sign containing the lagna is the 1st house, each subsequent sign a house. One sign = one house, no cusps, no ambiguity
• Rationale: whole-sign is the system of the classical texts our interpretations follow; it's also the system where house assignment is provably unambiguous — which matters because an off-by-one house error was the single most damaging bug class found during our verification (it had produced false Mangal dosha flags)

Step 5 — Vimshottari dasha (exact boundaries)

• Dasha lord at birth from the Moon's nakshatra (Ashwini → Ketu, Bharani → Venus, …)
• Balance of dasha from the Moon's position within the nakshatra, computed to the day
• Sequence follows the standard 120-year cycle (Ketu 7, Venus 20, Sun 6, Moon 10, Mars 7, Rahu 18, Jupiter 16, Saturn 19, Mercury 17)
• Antardashas (sub-periods) computed proportionally, with boundaries exact to the day — our verification caught and fixed a historical off-by-one-day boundary error plus antardasha drift

Step 6 — Vargas, yogas, and derived layers

From the verified positions, the engine derives:

• All 16 vargas (divisional charts) — D1 through D60 per Parashara's Shodasavarga, verified chart-by-chart
• Nakshatras and padas for all planets and lagna
• 23 yogas detected against classical definitions (Pancha Mahapurusha, Dhana yogas, Raja yogas, etc.)
• KP sub-lords (verified 175/175 in testing)
• Ashtakvarga — with the Sarvashtakvarga = 337 invariant checked as a correctness tripwire
• Mangal dosha with classical cancellations (not just the flag — the exceptions that un-flag it)
• Gochar (transit) engine for current planetary periods against the natal chart
• Lal Kitab layer and retrograde detection

What we verify (and how often)

Verification isn't a one-time event. The methodology:

• 53-chart sweep across dates (1900–2100), latitudes (equator to polar edge cases), DST transitions, leap years, and nakshatra/dasha boundary moments
• Reference: Swiss Ephemeris positions; classical texts for technique definitions
• Tolerance: ≤0.005° on positions; exact-match on discrete quantities (dasha lords, yoga detection, varga signs)
• Regression: the sweep re-runs against every engine change — a fix in one lane can't silently break another

During verification we found and fixed 19 calculation bugs, documented publicly: the house off-by-one, dasha boundary errors, a wrong Karana formula (wrong 6 days out of 7), Yamagandam/Gulikai table errors, porutham and guna-milan scoring bugs, a missing Mangal-dosha cancellation, invalid-timezone mishandling, and a dropped Ketu (South Node missing from charts entirely — caught by the sweep). We publish the bug list because a test suite that never finds bugs isn't testing. (Full verification log)

What we deliberately don't do

• No "premium accuracy" tier. The math is either right or wrong; pricing tiers don't change arithmetic.
• No hidden ayanamsa. Lahiri is stated; if options are added later, they'll be labeled.
• No silent defaults on ambiguous input. Bad timezone data fails loudly rather than guessing.
• No interpretation presented as computation. Dashas are computed; what they mean is interpretation, labeled as such. (Epistemology)

Reproduce it yourself

Everything above is checkable:

1. Generate your chart free at kundli.site/kundli — note positions to the arc-minute
2. Pull reference positions from the Swiss Ephemeris test page (Astrodienst publishes one) for the same UTC moment
3. Subtract Lahiri ayanamsa for your date; compare

Agreement within 18 arcseconds is the expected result. If you find a larger discrepancy with a reproducible case, that's a bug report we'll act on — it's happened before, and the fix list above is the proof.

Frequently asked questions

Which ayanamsa does kundli.site use?

Lahiri (Chitrapaksha) — the Indian Calendar Reform Committee standard and mainstream Indian default. It's computed date-specifically, not as a constant.

Which house system does kundli.site use?

Whole-sign houses — the classical Parashari default where each sign is a house. This is stated publicly and is part of why house assignment is unambiguous in our engine.

What ephemeris does kundli.site use?

A homegrown engine benchmarked to Swiss Ephemeris parity (NASA JPL DE431/DE441-derived reference, ≤0.005° tolerance across 53 verification charts).

How does kundli.site handle birth time timezones?

City-level timezone lookup with date-aware historical DST rules. Ambiguous or invalid inputs are rejected rather than silently guessed — timezone error is the industry's #1 real-world chart killer.

How are dasha boundaries calculated?

Vimshottari dasha from the Moon's nakshatra position, balance computed to the day, standard 120-year sequence, antardashas proportional. Boundaries verified exact against reference computations.

Does kundli.site calculate divisional charts?

Yes — all 16 vargas (D1–D60 per Parashara), each verified in the test sweep, plus navamsa-focused analysis in reports.

Can I check kundli.site's math independently?

Yes — that's the design goal. Take our arc-minute positions, compare against the Swiss Ephemeris test page minus Lahiri ayanamsa for your date. Methodology is published precisely so you don't need our word.

Why publish the bugs you fixed?

Because a verification process that never finds bugs isn't verifying. The 19 fixed bugs — including the house off-by-one causing false Mangal dosha flags — are evidence the testing is real, and each fix is regression-tested.