How Nakshatra Is Calculated: From Moon Degree to Pada

To find a birth star, an app needs just the Moon's sidereal longitude at the birth moment. Everything else is two divisions.

A nakshatra, or birth star, is one of 27 equal slices of the Vedic zodiac. Each slice is 13°20′ wide, which is 360 ÷ 27. Every nakshatra is then cut into 4 equal parts of 3°20′, called padas. Our rulebook states this as rule PA-05.

So the method has three steps. First, get the Moon's position in degrees, from 0 to 360. Second, divide it by 13°20′. Drop the decimals and add 1, and you have the nakshatra number. Third, take what is left over and divide it by 3°20′. Drop the decimals and add 1 again, and you have the pada.

Take John Doe, born on Aug 15, 1990, at 10:30 AM in New York. Our API puts his Moon at 54.575019°. Then 54.575019 ÷ 13.3333 = 4.09, so he is in nakshatra 5, Mrigashira. He is 1°14′30″ into it, and 1.2417 ÷ 3.3333 = 0.37, so he is in pada 1.

That is the whole answer. The rest of this post covers the parts that break in real apps: the Moon's speed, birth-time errors and one rounding bug. Every number comes from our own API, run in October 2026.

Step 1: Get the Moon's sidereal longitude

The Moon's position is an angle around the sky, measured along the Sun's yearly path. Western astrology counts it from the spring equinox. Vedic astrology counts it from a point fixed among the stars. This second count is called the sidereal zodiac.

The gap between the two counts is the ayanamsa. Our API uses the Lahiri ayanamsa unless you ask for another. On John's birthday it was 23.726073°.

His Western Moon was at 78.301092°, which is 18°18′ into Gemini. Subtract the ayanamsa, and his Vedic Moon is at 54.575019°, or 24°34′30″ into Taurus. Only the Vedic number works for nakshatras.

If your app takes Western positions from another library, this subtraction is your job. Skip it, and the result lands about 1.8 nakshatras too far along. Which ayanamsa to pick is its own question. We measured how often it changes a birth star in our ayanamsa guide.

Step 2: Divide by 13°20′ for the nakshatra

Divide the Moon's position by the width of one nakshatra: 54.575019 ÷ 13.333333 = 4.093. Drop the decimals to get 4. Four whole nakshatras sit behind the Moon, so it is in the 5th.

The 5th nakshatra is Mrigashira. It runs from 53°20′ to 66°40′. Its ruling planet, the nakshatra lord, is Mars.

Count from Ashwini, which starts at 0°, and end with Revati, which ends at 360°. Our API spells the names the standard way, such as Hast and Mool. Other data sources may write Hasta or Mula. So turn each name into its number once, and compare numbers in your code.

Step 3: Divide what is left by 3°20′ for the pada

Subtract the start of Mrigashira from the Moon: 54.575019 − 53.333333 = 1.241686°. That is 1°14′30″ into the nakshatra.

Divide by the width of one pada: 1.241686 ÷ 3.333333 = 0.373. Drop the decimals to get 0, then add 1. John's Moon is in pada 1, which runs from 53°20′ to 56°40′.

A pada never crosses a sign line. Each 30° sign holds exactly 9 padas. So the nakshatra and pada together also tell you the Moon sign. Mrigashira pada 1 is always in Taurus.

The code, tested against our API

Here is the same math in JavaScript. We ran it on 3,285 Moon positions that our API returned, and it matched the API's nakshatra and pada every time.

const NAKSHATRAS = [
  "Ashwini", "Bharani", "Krittika", "Rohini", "Mrigashira", "Ardra", "Punarvasu",
  "Pushya", "Ashlesha", "Magha", "Purva Phalguni", "Uttara Phalguni", "Hast",
  "Chitra", "Swati", "Vishakha", "Anuradha", "Jyeshtha", "Mool", "Purva Ashadha",
  "Uttara Ashadha", "Shravan", "Dhanishtha", "Shatabhisha", "Purva Bhadrapada",
  "Uttara Bhadrapada", "Revati",
];
const NAKSHATRA_WIDTH = 360 / 27; // 13°20′
const PADA_WIDTH = NAKSHATRA_WIDTH / 4; // 3°20′

// moonLongitude: the Moon's sidereal (Vedic) position, 0 to 360 degrees.
function findNakshatra(moonLongitude) {
  const index = Math.floor(moonLongitude / NAKSHATRA_WIDTH) % 27;
  const degreesInto = moonLongitude % NAKSHATRA_WIDTH;
  const pada = Math.floor(degreesInto / PADA_WIDTH) + 1;
  return { number: index + 1, name: NAKSHATRAS[index], pada };
}

findNakshatra(54.575019); // { number: 5, name: "Mrigashira", pada: 1 }

Divide by 360 / 27, not by 13.333. The rounded number puts every edge a little too early, by up to 32 arc seconds. An arc second is 1/3,600 of a degree. Near the end of the circle it gets worse. Above 359.991°, dividing by 13.333 gives nakshatra 28, which does not exist. At the Moon's average speed, that window is about 1 minute of birth time. With 13.333, 2 of our 3,285 Moons got the wrong nakshatra. A test with a few sample births will not catch that.

How fast the Moon moves through a nakshatra

The Moon does not move at a steady speed. We asked our API for the Moon at 10:30 AM in New York on every day of 1990. Its slowest day was Oct 23, 1990, at 11.80° a day. Its fastest was Dec 2, 1990, at 15.32° a day. The average was 13.20° a day.

So "about one day per nakshatra" is right on average, but it can be off by about 3 hours either way. At the average speed, the Moon moves 0.55 arc minutes every minute. An arc minute is 1/60 of a degree.

John was born on a fast day, at 14.258194° a day. Our panchang endpoint shows his Moon entered Mrigashira at 8:24:36 AM on Aug 15, 1990. It left at 6:52:22 AM the next day, 22.5 hours later.

His birth at 10:30 AM came 125 minutes after the Moon entered Mrigashira pada 1. The Moon moved into pada 2 at 2:01 PM, 211 minutes after his birth. So John's nakshatra and pada are safe for any birth-time error under 2 hours.

You can get these margins without a search. Divide the degrees to the edge by the speed, then multiply by 1,440 minutes. For John's next pada: 2.091648 ÷ 14.258194 × 1,440 = 211 minutes. That matches what we found by stepping through the API.

How often a birth-time error changes the answer

John was far from an edge. Some births are not, and a birth time written down by hand may be rounded. So we measured how often a small error changes the result.

We took the same 365 births, one per day of 1990 at 10:30 AM in New York. We sent each one at its own time, then 5, 15, 30 and 60 minutes earlier and later. That is 9 calls per birth, 3,285 in all. We counted a birth as changed if either the earlier or the later time gave a different answer:

Read it this way. If your users' times may be 30 minutes off, about 1 in 18 could have a different birth star. About 1 in 5 could have a different nakshatra or pada. The pada changes 3 to 4 times as often as the nakshatra, because its edges come four times as often.

We checked the counts with the speed formula above. It gave the same numbers in all eight cells.

What to show when a birth is near an edge

The nakshatra feeds other features. It picks the first planet period in a Vimshottari dasha. It also sets four of the eight scores in kundli matching. So a wrong birth star can change several screens at once.

Try it on a real birth first. Our free nakshatra finder runs the same POST /v1/planets call shown below. Enter a birth close to an edge and watch the star change.

Two choices help your users here:

Show the margin. Use the formula from the speed section to find the minutes to the nearest edge, earlier and later. If either is under 30 minutes, show both possible stars and ask the user to check the birth time.

Say when you guessed the time. If a user does not know the time, our nakshatra finder uses noon. It then tells the user that the answer could be the star before or after. Your app should do the same.

What the API returns

POST /v1/planets returns the nakshatra, its lord and the pada for the rising sign and all nine planets. You do not run the math yourself. Here is John's Moon:

John Doe, born Aug 15, 1990, at 10:30 AM in New York (America/New_York, daylight saving time)

{
  "name": "Moon",
  "longitude": 54.575019,
  "sign": "Taurus",
  "degree_dms": "24 : 34 : 30",
  "nakshatra": "Mrigashira",
  "nakshatra_lord": "Mars",
  "pada": 1,
  "speed": 14.258194
}

The speed field is in degrees a day, so you can work out the margins above from one answer. Add ?lang=hi, and the names come back in Hindi, such as मृगशिरा for Mrigashira. The English name stays in nakshatra_en, so your code keeps one key.

Other endpoints carry the nakshatra too. POST /v1/panchang gives it for the birth moment. GET /v1/panchang/daily gives the day's nakshatra with its starts and ends times, which is where John's 8:24:36 AM came from. POST /v1/matching/nakshatra scores two people from their nakshatra and pada alone, for users who do not know their birth times.

See every field. The API reference lists each response field for the planets call. The birth chart feature page shows what else comes with it.

The math behind a birth star is two divisions. The hard part is the edge. The Moon crosses a pada edge about every 6 hours. A rounded birth time can carry a user across it. Measure the margin, and tell the user when it is thin.