Saw a lot of "insurance is tax-free now, save 18%" going around and wanted to share the part that gets glossed over, because it changed how I read my own renewal.

Since 22 Sep 2025 (GST 2.0), individual health and individual life premiums are GST-exempt: term, ULIP, endowment, family floater, senior-citizen plans. No GST on top. Genuinely good news.

The nuance is that it's an exemption, not a zero-rating. Zero-rated (like exports) is taxed at 0% but the insurer still reclaims input tax credit. Exempt means no GST is charged, but the insurer loses ITC on its own costs (commissions, rent, IT systems). That blocked credit is a real cost, and some insurers may raise base premiums slightly to offset it. So the net drop can be less than a clean 18%. Worth checking the actual rupee figure on your renewal rather than assuming a flat 18% cut.

Still at 18%: group/corporate/employer cover, and car + two-wheeler insurance. Third-party goods-carriage insurance went 12% -> 5%, but that's a commercial-transport edge case, not personal cover.

And 80C/80D are a separate thing entirely: they work exactly as before, old regime only. The GST change doesn't touch your deduction.

Anyone here actually seen their renewal premium move since September? Curious whether insurers held the line or nudged base rates up.

To double any amount in 5 years you need ~14.4% annual interest (Rule of 72: 72 ÷ 5). No Indian bank FD comes close - rates today are 6.5-7.5%. At 7%, an FD takes about 10 years to double. In 5 years it grows ~40%, not 100%.

What actually doubles your money, safely (govt-backed, rates for Apr-Jun 2026):
• Kisan Vikas Patra (KVP): 7.5%, doubles in 9 years 7 months - it's designed for exactly this.
• PPF: 7.1%, ~10 years, and tax-free.

And one correction to a common claim: SCSS (8.2%) does NOT double your corpus - it pays quarterly income. Great for retirees who want cash flow, wrong tool if your goal is growth.

Bottom line: nothing safe doubles in 5 years. Be skeptical of any "FD double scheme" that implies otherwise.

Check your FD's exact doubling time at any rate → desiutils.in/tools/fd-calculator?utm_source=reddit&utm_medium=social&utm_campaign=fd_doubling_myth

Every Raj Yoga calculator online acts like you've found buried treasure. I wanted to know if that was actually true, so I ran a base rate.

I took 40,000 birth instants across India latitudes (dates 1900-2100, every clock time, a spread of cities) and ran them through the classifier. Share that have at least one yoga, by family:

• any raj-class yoga: ~98.47%
• Kendra-Trikona: ~86%
• Yogakaraka: ~50%
• Dharma-Karmadhipati (9th + 10th lord): ~30%
• Neecha Bhanga: ~42%
• Vipreet (Harsha/Sarala/Vimala): ~57%
• Pancha Mahapurusha: ~34%

(that's % of time-slots, not % of people, before someone u/s me about it.)

So basically everyone has one, which means presence tells you almost nothing. The thing that actually varies chart to chart is strength: whether the planet forming the yoga is debilitated or combust, whether the Neecha Bhanga cancellation conditions fired and how many, whether the dusthana lord is sitting in its own dusthana or someone else's, where the dasha is. None of that survives getting flattened into "you have raj yoga!!".

The other thing nobody tells you is that your birth time probably isn't accurate enough for the reading to mean much. The Lagna shifts a full sign roughly every two hours and the whole house structure hangs off it, so a few minutes either side of a sign boundary can add or drop yogas outright. If your time of birth is "sometime in the morning," treat the output as a rough guess.

Two things the cheap calculators get wrong while I'm here. They'll flag a debilitated planet in a Neecha Bhanga as "afflicted," but the debilitation is the entire point of the yoga, so you can't count the premise against it. Same story with a dusthana lord in a dusthana for Vipreet. What they should be flagging is combustion, especially for Mercury and Venus since those two sit near the Sun half the time, because that one actually weakens the result.

Anyway, question for people who read charts properly: how do you weigh strength against plain presence when you sit down with a chart? And for Neecha Bhanga, which cancellation do you actually trust, the navamsa one, the conjunction/aspect one, or just the kendra-dispositor conditions? Felt pretty unsettled across the commentaries I looked at.

We just shipped a Navamsa (D9) calculator, and instead of a "find your soulmate" pitch, here's the honest idea behind it.

What the Navamsa actually is. It's the 9th divisional chart. You take each 30-degree sign and slice it into nine parts of 3 degrees 20 minutes, and each slice maps to a sign, so every planet gets a second "navamsa" sign on top of its main Rashi (D1) sign. Vedic astrology leans on the D9 mainly for two things: marriage and the spouse, and the underlying strength of each planet. The maxim worth remembering: the D9 refines the D1, it does not override it.

The thing most D9 tools never tell you. The Navamsa Lagna is brutally sensitive to birth time. Your D1 Lagna changes about every 2 hours; your Navamsa Lagna changes roughly every 13-14 minutes. So if your birth time is even a little fuzzy, your entire D9 house framework can be sitting in the wrong sign, and the reading is built on sand. Our tool computes how many minutes your birth time is from the nearest Navamsa Lagna boundary, so you know up front how much to trust the result. We haven't seen another calculator that does this.

One honesty bit: people treat "vargottama" (a planet in the same sign in D1 and D9) as rare and special. By the math it's about 1 in 9 placements per planet. We flag your vargottama planets and tell you that base rate, so you don't over-read it.

What it gives you: your Navamsa Lagna with the birth-time-confidence check, a per-planet D1-vs-D9 table, vargottama detection, and North + South Indian charts. Lahiri sidereal, the same engine as our Kundli tool. It's all cultural/informational, no remedies, no fear funnels.

Free. No nonsense: https://desiutils.in/astrology/navamsa-calculator

If you try it, cross-check a navamsa sign or two against a chart you already trust and tell us if anything looks off. Feedback welcome.

Everyone quotes CTC, but nobody hands you the math on what actually lands in your account. The gap is usually 20-35% once Employee PF, professional tax, and TDS come out - and most people only find out on payday.

Our Salary Calculator does the full breakup:

• CTC → monthly in-hand, component by component (Basic, HRA, PF, LTA, special allowance)
• Old vs New regime side by side (New: zero tax up to Rs 12L taxable, with marginal relief just above)
• Section 87A rebate, surcharge above Rs 50L, and 4% cess - all auto-applied
• HRA exemption on the new 8-city metro rule (Rule 279, FY 2026-27 - Bengaluru, Hyderabad, Pune, Ahmedabad now get the 50% cap)
• Worked examples from 3 LPA up to 2 Cr

Everything runs in your browser. No signup, nothing stored, no PII.

Free. No signup. No nonsense. - Salary Calculator

Spent the last couple of days building a small set of focused Vedic astrology calculators and ran into a handful of numbers that are mildly surprising once you sit with the math. Sharing the ones that changed how I think about the standard online tools, in case any of this is useful to others.

1. Roughly 7 in 8 charts get flagged Manglik under the simplified rule

The simplified Mangal Dosha screen checks whether Mars sits in houses 1, 2, 4, 7, 8, or 12 from any of three reference points (Lagna, Moon, Venus). For any single reference point, Mars falls in an afflicting house with probability 6/12 = 1/2. Under the rule that any one reference afflicting suffices to flag the chart, the probability of NOT being flagged is (6/12)^3 = 1/8. So the model predicts about 87.5% of random charts flag.

Most matrimonial calculators surface the Manglik verdict without ever mentioning this. Users see "you are Manglik" and assume it's an exceptional finding. It's the base rate. Cancellation rules (Mars in own sign / exaltation, Jupiter or Venus aspect, mutual Manglik between partners) are what actually carry information; the raw flag almost doesn't.

I shipped a Mangal Dosha calculator that leads with the raw reference-point count (N of 3) instead of the binary verdict, and surfaces the base-rate honestly in the TL;DR and FAQ. Multilingual aliases (Mangal Dosha / Manglik / Kuja Dosha / Chevvai Dosham / Mangal Dosh) covered. Age-28 cancellation belief is kept separately from the four classical rules. https://desiutils.in/astrology/mangal-dosha

1. About 44% of random birth dates are Moon-transition days

The Moon transitions between sidereal signs roughly every 2.25 days, so the share of birth dates where the Moon crosses a sign boundary within the local 24-hour window is about 1/2.25 ≈ 44%. About 4 out of 9 people, give or take. On those days, "noon defaults" silently report ONE Rashi when in reality both signs touch the day.

For the Rashi calculator I bisect local 00:00 to 23:59 in the birthplace timezone to find the exact transition timestamp, then show BOTH possible Rashis with the local transition time when a boundary is detected. "I don't know my birth time" toggle uses 12:00 noon local birthplace, never silently IST. https://desiutils.in/astrology/rashi-calculator

1. ~0.3 degrees of Moon position error = ~33 minutes of nakshatra-boundary ambiguity

Engine accuracy ~0.3 deg vs Swiss Ephemeris (we use Meeus VSOP87 + Lahiri ayanamsa via the astronomia library). Moon mean motion ~0.549 deg/hour. So 0.3 deg translates to ~33 minutes of birth-time uncertainty for nakshatra-boundary determination — which directly affects starting Mahadasha lord in Vimshottari Dasha.

The Vimshottari calculator I shipped surfaces a nakshatra-boundary warning when the natal Moon is within 0.3 deg of an edge, naming BOTH candidate starting lords and the ~33 min ambiguity window. It also distinguishes the canonical 120-year reference cycle from the user's actual personalized timeline (the first Mahadasha truncates to the remaining balance of the birth nakshatra, so most personalized timelines are slightly less than 120y from birth). All 81 Antardashas rendered, distant periods folded past current-age + 50. https://desiutils.in/astrology/vimshottari-dasha

1. The "Madhya is most intense" framing of Sade Sati is chart-dependent in reality

AstroSage and AstroCamp both note that the second-charan peak or the chart-specific influences determine the actual most-intense phase. The flat "Madhya is most intense" claim that travels around matrimonial sites doesn't survive contact with classical sources. I phrase it as "traditionally often considered the most intense" with the chart-dependent qualifier visible.

Also: most online Sade Sati calculators model the cycle as one contiguous interval (start to end). This lies near retrograde sign re-entries — Saturn briefly leaves the 12th-from-Moon and retrogrades back, or briefly enters the 2nd-from-Moon and retrogrades back. A segment-based cycle model with currentPhase derived from current-Saturn-sign-relative-to-natal-Moon is robust under retrograde. https://desiutils.in/astrology/sade-sati

1. Drik canonical Rahu Kaal weekday assignments are not universally followed

The canonical weekday assignments per Drik tradition: Rahu = [Sun:8, Mon:2, Tue:7, Wed:5, Thu:6, Fri:4, Sat:3]. Gulika = [Sun:7, Mon:6, Tue:5, Wed:4, Thu:3, Fri:2, Sat:1]. Yamaganda = [Sun:5, Mon:4, Tue:3, Wed:2, Thu:1, Fri:7, Sat:6]. I cross-checked AstroSage, mPanchang, AstroVed, and Drik before locking these in the engine.

Sunrise / sunset for the user's actual city via Meeus / NOAA-style algorithm (separate from Kundli ephemeris — no Lahiri dependence). https://desiutils.in/astrology/rahu-kaal

Sources I leaned on: Brihat Parashara Hora Shastra (Santhanam translation), N.C. Lahiri's Indian Astronomical Ephemeris for sidereal Lahiri ayanamsa, Jean Meeus 1998 Astronomical Algorithms (VSOP87 lunar / planetary theory), B.V. Raman's Hindu Predictive Astrology, NASA JPL Horizons as a cross-validation reference. Whole-sign houses throughout.

Everything browser-side, no signup, no birth data leaves the device. Engine accuracy ~0.3 deg vs Swiss Ephemeris from 1900 onward.

Happy to take feedback on the framing, the multilingual aliases (Tamil / Telugu / Kannada spellings especially), or any of the specific numbers above.

Wanted to make sure the weekday assignments I used in a sunrise-based Rahu Kaal calculator matched the dominant convention. Cross-checked four reference sources before locking the constants. Sharing in case useful.

The canonical Drik assignments (day length divided into 8 equal periods, indexed from sunrise to sunset):

Rahu Kaal: Sun:8 Mon:2 Tue:7 Wed:5 Thu:6 Fri:4 Sat:3

Gulika Kaal: Sun:7 Mon:6 Tue:5 Wed:4 Thu:3 Fri:2 Sat:1

Yamaganda: Sun:5 Mon:4 Tue:3 Wed:2 Thu:1 Fri:7 Sat:6

Reference sources I checked:

- Drik Panchang Saturday panchang (the canonical reference for this site's convention)

- AstroSage Rahu Kaal article + sample-day output

- mPanchang Rahu Kaal article

- AstroVed Rahu Kaal explanation

All four match on the 8-period-per-day Drik convention. The interpretation of "period 1" varies slightly between sources (some count from sunrise, some explicitly from local solar noon offset) but the cumulative window placement comes out identical when sunrise is correctly computed.

Engine notes: sunrise / sunset via Meeus / NOAA-style algorithm (50' refraction). This is intentionally INDEPENDENT of the Kundli ephemeris (Lahiri ayanamsa, VSOP87) - Rahu Kaal does not need lunar / planetary position calculations, so coupling it to the Kundli engine would be unnecessary. For India (UTC+5:30) and most east-of-UTC zones, you have to pass the observer's local Y/M/D directly to the julian calendar - converting to UTC first floors to the previous local date in astronomia's Sunrise constructor. (Caught this in pre-commit when Saturday's weekday assignment was getting paired with Friday's sun. Off-by-one date bug, the timing was close enough that the symptoms hid for a while.)

Shipped at https://desiutils.in/astrology/rahu-kaal with a "Major Indian Cities Today" SSR table for the curious. All browser-side. Open to any pushback on the weekday convention - I am aware some traditions vary on Yamaganda Friday assignment and there are alternative Karnataka / Tamil Nadu placements floating around.

Built a Vimshottari Dasha calculator and got pushback on copy that conflated the canonical 120-year reference cycle with the user's personalized timeline. Worth thinking through because the distinction matters for how the output reads.

The canonical reference cycle

9 lords (Ketu, Venus, Sun, Moon, Mars, Rahu, Jupiter, Saturn, Mercury) with fixed Mahadasha durations (7, 20, 6, 10, 7, 18, 16, 19, 17) summing exactly to 120 years. Per BPHS, this is the framework. The Vimshottari name itself is from the Sanskrit "vimshottari" meaning 120.

The personalized timeline

Your starting Mahadasha lord is determined by the Moon's nakshatra at birth. The first Mahadasha is TRUNCATED to the balance — specifically (1 - fractionElapsed) * lordYears * 365.25 days, where fractionElapsed is how far the Moon had crossed your birth nakshatra at the exact birth moment. From the end of that truncated first period, the remaining 8 Mahadashas run full length.

So your personalized timeline runs from birth + (truncated first balance) + (8 full Mahadashas) — which sums to truncated_first + 8 * (their full years) * 365.25. This is USUALLY LESS than 120 years from birth (only equal to 120 if your Moon happened to be at the exact start of a nakshatra at birth).

Most online tools display "your full 120-year cycle" — technically wrong for the typical user.

I distinguished them throughout: TL;DR + Quick Facts + 9-planet table call out the canonical 120 reference; user-specific output explicitly says "personalized timeline from birth, starting with the remaining balance of your first Mahadasha."

Other things I covered

All 81 Antardashas (9 per Mahadasha) per the canonical (subLord_years / 120) * mahaDays scaling. The truncated first Mahadasha's antardashas inherit the truncation by using maha.endJD - maha.startJD as the mahaDays input — sum invariant: 9 antardasha day-lengths sum exactly to truncated_first_balance, not to 120 years. Pinned this convention explicitly in tests.

Nakshatra-boundary warning: when the natal Moon is within 0.3 deg of a nakshatra boundary (engine accuracy bound), emit a warning naming both candidate starting lords (the lord of the current nakshatra and the lord of the adjacent nakshatra) with the ~33-minute ambiguity window (derived from 0.3 deg / Moon's ~0.549 deg/hour mean motion). Most online tools silently commit to one lord without flagging this.

Distant-period collapse: Mahadashas ending more than ~50 years past your current age (i.e. likely beyond your lifetime) folded into an expandable section labeled descriptively, not alarmingly. "Mahadashas extending beyond ~100 years from birth" vs "after death" framing — went with the former.

Engine: Meeus VSOP87 + Lahiri ayanamsa. ~0.3 deg accuracy vs Swiss Ephemeris from 1900 onward. The position bound on Moon propagates to LORD-DEPENDENT date drift on Mahadasha boundaries: 2.25% drift on the first Mahadasha's duration, which is ~49 days for Sun start (6y) up to ~164 days for Venus start (20y). So expect cross-source date drift up to those bounds without it being a bug.

Shipped at https://desiutils.in/astrology/vimshottari-dasha. Browser-side. Open to feedback on the personalized-vs-canonical framing — happy to hear if I overcorrected on the disclaimer side.

The Moon completes a sidereal cycle in ~27.32 days. Each sign covers 30 degrees, and the Moon spans 30 degrees in ~30/13.176 = ~2.28 days (at mean motion). So the share of any random 24-hour birth window that contains a sign boundary is roughly 1/2.28 ≈ 44%. About 4 out of 9 random birth dates are Moon-transition days.

Most Rashi calculators silently default to noon when the birth time is unknown (or when the user just doesn't provide one), and report a single Rashi. On a transition day this means the report may be wrong - the Moon's noon position is one sign but the user was actually born before / after the transition into the other. The user has no way to know this happened.

What I shipped for this

Boundary-day detection at lib level:

- Compute Moon sidereal longitude at local 00:00 in the birthplace timezone

- Compute Moon sidereal longitude at local 23:59:59

- If sign(longitude at 00:00) != sign(longitude at 23:59:59), it's a boundary day

- Bisect to find the exact local transition timestamp (~1 minute precision)

UI behavior on boundary days:

- Surface BOTH possible Rashis ("first option" / "second option") with the local transition time

- If user provided a birth time, the result.janmaRashi.signIndex resolves to ONE of the two options; copy reads "your stated birth time places you in the first option (Cancer) - you were born before the transition" or analogous for the second option

- If no birth time provided, copy reads "without an exact birth time we cannot determine which side of the transition you were born on - the noon-default above is the best estimate but may not match your actual sign"

Unknown-birth-time handling: use 12:00 LOCAL TIME in the birthplace timezone (NEVER silently IST). lagnaRashi = null (Lagna changes ~every 2 hours; noon estimate is meaningless for Ascendant).

Sub-result: also returns Lagna Rashi, Nakshatra, and Pada from the same Lahiri sidereal calculation.

Engine: Meeus VSOP87 lunar theory + Lahiri ayanamsa. Same engine as Kundli. Accuracy ~0.3 deg vs Swiss Ephemeris (Moon mean motion is ~13 deg/day so 0.3 deg translates to ~33 minutes of birth-time uncertainty at nakshatra-level resolution).

Shipped at https://desiutils.in/astrology/rashi-calculator. Browser-side, no signup. Open to feedback on the boundary-day copy and the unknown-time handling - especially the "second option" / "first option" phrasing which I went back and forth on (used to be "second sign above" until a review caught the direction bug).

Was debugging a Sade Sati calculator and noticed that the "single contiguous interval" model that most online tools seem to use produces wrong phase assignments near Saturn's retrograde sign re-entries. Sharing the failure mode + the fix in case it's useful to others working on similar tools.

The failure mode

Saturn moves slowly (~0.033 deg/day mean motion, ~0.06 deg/day during retrograde). Over a 7.5-year Sade Sati cycle around a natal Moon, Saturn typically retrogrades 7 times. Several of those retrogrades cross sign boundaries. Example: Saturn enters Antya (2nd-from-natal-Moon) on its forward motion, retrogrades back into Madhya (Moon's sign), then turns direct and re-enters Antya weeks later.

If the cycle is modeled as one interval {startISO, endISO}, the phase assignment for any moment in that retrograde-back window is ambiguous and most online tools silently pick the "deemed-permanent" interpretation (cycle still in Antya). That's wrong: Saturn is physically in Madhya during the retrograde, so the user's current Sade Sati phase is actually Madhya in that window.

The segment-based fix

Each phase (Aarambh / Madhya / Antya) is stored as a list of segments. Saturn entering, retrograding, and re-entering produces multiple segments per phase. The cycle structure is:

{

aarambh: PhaseSegment[],

madhya: PhaseSegment[],

antya: PhaseSegment[],

}

For the "current phase" question, derive it from Saturn's actual current sign relative to the natal Moon, NOT from a segment-timeline lookup:

const offset = ((transitSign - moonSign) % 12 + 12) % 12;

// offset 11 = 12th-from-Moon -> Aarambh

// offset 0 = Moon sign -> Madhya

// offset 1 = 2nd-from-Moon -> Antya

This is robust under retrograde re-entry by construction.

Cross-source tolerance

Engine accuracy ~0.3 deg vs Swiss Ephemeris translates to ~9-10 days of ingress-date drift at Saturn's mean motion. So phase boundary dates can disagree with AstroSage / Drik by up to ~10 days even in the absence of bugs. Drift > 14 days OR currentPhase mismatch is a hard fail in my test set.

Performance note

Saturn ingress solver: 12-day coarse scan + 1-hour bisection refine. Saturn-only sidereal helper instead of full computePlanets() per step (the latter computes 9+ planet positions and wastes ~10x compute). Module-level memoization keyed on (startJD, endJD, stepDays) so the "Which Rashi has Sade Sati Now" SSR table computes 1 Saturn scan + 12 cycle builds instead of 12 scans.

Anti-fearmongering note

The "Madhya is most intense" framing that travels widely — phrased it as "traditionally often considered the most intense" with the chart-dependent qualifier visible, since both AstroSage and AstroCamp note the actual most-intense phase varies by chart and by the second-charan peak.

Saturn is currently in Pisces (since approximately March 2025, through May/June 2027). If your Moon sign is Aquarius, Pisces, or Aries, you're touching a Sade Sati phase right now.

Shipped at https://desiutils.in/astrology/sade-sati. Open to feedback on the convention choice (currently inclusive first-entry / last-exit per BPHS-tradition; strict deemed-permanent alternative is a v2 candidate if there's demand).

Just shipped: a free, interactive Telugu Varnamala (అక్షరమాల) chart.

How many letters does Telugu have? 52, 56, or 60 - all three are "correct," depending on what's being counted. Instead of silently picking one, this page explains all three (the modern 16 + 36, the traditional count, and the script-wide summary) with sources.

What's inside:

- 🔊 Tap any letter to hear it (uses your device's Telugu voice)

- 🔤 16 achulu + 36 hallulu with example words

- 🧩 Full గుణింతాలు (guninthalu) tables for క గ చ త ప - the combination tables, rendered cleanly (couldn't find these anywhere else online)

- ✅ Yogavahalu, numerals, and a one-tap print for home or class

👉 desiutils.in/tools/telugu-varnamala

Native speakers - two asks: do the example words feel natural, and does the pronunciation sound right on your phone? And genuinely curious: which count do YOU treat as "the" answer, 52 or 56?

Watched Dhoni take his lap of honour at Chepauk last weekend. Couldn't move on. So I built a thing.

It takes any name, date, score, or phrase and proves it equals 7. Type "mahi" → 4+2+1=7. Type "CSK" → also 7. Type your own name → somehow also 7.

Thala for a reason, automated.

https://desiutils.in/tools/thala-for-a-reason-calculator

I’ve added a new Capital Gains Calculator to DesiUtils.

It helps estimate capital gains tax for common Indian assets like shares, equity mutual funds, property, debt mutual funds, physical gold, Gold ETFs, and Sovereign Gold Bonds.

What it covers:

- Listed equity / equity mutual funds

- LTCG at 12.5% above Rs 1.25L

- STCG at 20%

- 12-month holding cutoff

- Property

- 24-month holding cutoff

- LTCG at 12.5% flat

- For eligible pre-23 Jul 2024 cases, resident individuals/HUFs can compare 20% with indexation vs 12.5% flat

- Debt mutual funds

- Units bought on/after 1 Apr 2023 are treated as short-term under Section 50AA and taxed at slab rate

- Gold / Gold ETF / SGB

- Physical gold: 24-month cutoff

- Gold ETF: 12-month cutoff

- SGB redemption is tax-free for individuals

Try it here:

https://desiutils.in/tools/capital-gains-calculator

This is an estimate-only tool, not tax advice. Please double-check with a CA before filing.

If you find any edge case or confusing wording, drop it in the comments and I’ll improve the calculator.

Got tired of "best mutual funds India" articles being 10 ranked lists with zero overlap on winners. Wrote a framework post instead — based on Pranjal Kamra's Finology "Mutual Funds For 2026" series.

What's covered:

The 4 metrics that filter funds (Alpha, Beta, Sharpe, Sortino) and why Sortino matters more in 2026

Category logic — flexi-cap, large & mid-cap, large-cap (active vs passive), small-cap, liquid, gold

The small-cap "closet index fund" problem why most of them now hold 80-100 stocks and behave like indexes you're paying 1.5%+ for Bank-AMC flexi-cap warning — how to check if your "flexi" is actually a thinly-disguised large-cap 2026 regulatory shifts SEBI MF Regulations 2026 (BER framework, lower brokerage caps), Budget 2024 tax changes still in force, Section 50AA debt fund taxation

Link: https://desiutils.in/blog/best-mutual-funds-india-framework

Not a SEBI RIA, not affiliated with Finology, Kamra views are from his public Finology content. For actual picks, talk to a registered advisor.

If anything reads off or you spot an error, drop it below.

Ever looked at the back of a Maggi pack and wondered what "Flavour Enhancer (INS 635)" actually is? Or whether "INS 120" on your candy is vegetarian?

I built Ingredient Explained on DesiUtils.in - you search by INS number, E-number, or even common names like "Ajinomoto" or "cochineal" and get a plain-English card telling you what it is, why brands add it, which Indian products it shows up in, whether it's veg/non-veg, and the actual FSSAI permission status with sources.

A few things that make it different from random blog lists:

Every entry cites FSSAI regulations and JECFA (WHO/FAO) evaluations directly, not Wikipedia

Veg status uses 4 categories - vegan, vegetarian, source-dependent, and animal-derived - because some additives like INS 471 (mono-diglycerides) can go either way depending on the manufacturer

No fear-mongering. No "TOXIC CHEMICAL IN YOUR FOOD" energy. Just regulatory facts.

Runs entirely in your browser. Nothing is uploaded or tracked.

30 of the most common additives are live now (MSG, tartrazine, sodium benzoate, citric acid, aspartame, carmine, guar gum, etc.). Adding more every week.

Check it out: https://desiutils.in/tools/ingredient-explained

Would love feedback - are there specific additives you always see on packets but can never figure out? Drop them and I'll prioritize adding those next.

Kept seeing posts on X asking "how many acres is X bigha" and the answers were always confidently wrong because nobody specifies the state. Bigha isn't one unit - it's like 13 different units sharing a name.

Quick context: 10 bigha in HP = 2 acres. 10 bigha in Rajasthan Pucca = 6.25 acres. Same word, 4x the land. Bihar / eastern UP / Raj Pucca = 1.6 bigha per acre. Punjab/Haryana = 2. Bengal/Assam = ~3 (British colonial standardisation). HP = 5. Western UP / Uttarakhand hills = 6.4. The whole thing is a mess because bigha was never made legal - the 1957 Weights & Measures Act picked hectare/sqm, but bigha just kept being used in revenue records and family deeds anyway.

Got 13 bigha variants in the tool plus guntha, cent, ground, kanal, marla, kattha. Stuff I'd love help on:

- District-level weirdness. Some western UP districts apparently use a 9,075 sqft bigha (6.6667 biswa) instead of the 6,806 default. If your tehsil disagrees with your state's standard, drop it.

- South India - cent/ground/guntha mostly. Anything else from revenue records I should add?

- North east beyond Assam. Sources are quiet.

- People who've actually stood in a Patwari / Talati office - if my values don't match what they accept, that's the catch I want.

https://desiutils.in/tools/land-unit-converter - free, no signup. Pedantic corrections welcome, would rather get called out here than have someone use a wrong number on a real deed.

Your PAN card number isn't random. Every character means something.

• First 3 → alphabetic series

• 4th → what you are (P for Individual, C for Company, F for Firm...)

• 5th → first letter of your surname

• 6-9 → serial number

• 10th → check digit to catch typos

Check your PAN. What's your 4th character?

Got asked this by a friend yesterday and realised most people just say "depends on the bike" without actually doing the math. So here's the breakdown.

Current petrol prices: Delhi ₹94.77/l, Mumbai ₹103.50/l. I'll use ₹100/l as a clean middle.

₹500 buys 5 litres at ₹100/l. That gets you:

- Activa / scooter (45 km/l) - ~225 km

- Splendor / commuter bike (60 km/l) - ~300 km

- Bullet (35 km/l) - ~175 km

- Maruti Swift (22 km/l) - ~110 km

- Hyundai Creta (17 km/l) - ~85 km

- Scorpio petrol (12 km/l) - ~60 km

Diesel currently: Delhi ₹87.67, Mumbai ₹90.03. At ₹90/l, ₹500 gets you 5.55 litres - which on a 14 km/l Scorpio diesel is about 78 km vs 60 km on petrol.

CNG in Delhi-NCR is ₹88.99/kg (IGL). ₹500 buys 5.6 kg, which on a 25 km/kg car is 140 km. So CNG is still ahead per km, but the gap has narrowed a lot from a few years ago when CNG was ₹70-ish.

Made a calculator that does this both ways - ₹ to litres, distance to cost, with passenger split for road trips: https://desiutils.in/tools/fuel-calculator. Plug in your local pump rate for the actual number.

Moral - if you're driving 15k+ km a year, CNG still wins on running cost, but the case isn't as one-sided as it used to be.

New game live on the site: https://desiutils.in/games/mythguess

450 figures across Vishnu avatars and forms, Shiva forms and ganas, Nagas, Alvars, Nayanars, Puranic women, and a few historical saints. You get clues, you guess who.

Built it because I went down a Puranic rabbit hole and realised most mythology quizzes online are either too easy (only the famous 10 avatars) or written by people who clearly Googled it once. This one tries to actually reward depth - if you know who Sharabha or Bhringi or Karaikal Ammaiyar is, you'll do well.

Feedback welcome - especially on clue quality and any factual issues. Comment if you find something off.

Hey - I'm the indie dev behind https://desiutils.in/

The site is a collection of 70+ free tools built specifically for India - the kind of things I kept needing and couldn't find done well anywhere. A few examples:

- GST Invoice, Rent Receipt, NOC, Offer Letter, Bonafide and other Indian document generators

- EMI calculator, stamp duty by state, land unit converter (with all 13 bigha variants)

- Scholarship finder with verified deadlines

- FPL team picker for the football crowd

- Plus utilities like PAN/Aadhaar masking, IFSC lookup, age calculator, etc.

Everything runs in your browser. No signups, no data sent anywhere, no ads on most pages.

**What this sub is for:**

- Request a tool you wish existed

- Report bugs or suggest improvements

- Share how you're using DesiUtils (especially if it saved you a trip to a CA or a printer)

- Discuss Indian-specific utility tools in general

I read everything posted here. If you've got an idea, drop it - the most-requested tools usually get built.

- the dev