For a while there, many people thought vitamin D was magical—that it could improve bones, the heart, infections, cancer, heart disease, longevity, even mental health. But among people I respect, opinion is now overwhelmingly that taking vitamin D does nothing unless you’re severely deficient. The central argument is that while vitamin D levels are correlated with ~all positive health outcomes, when you actually test vitamin D supplements against placebo in randomized trials, nothing ever happens.

That’s what I used to think, too. But I’ve come to think the skeptics have over-corrected. Yes, randomized trials have shown the magical correlations are not causal. But if you start with non-insane expectations, the trials look like weak but positive evidence. And if you consider what we know about biology and evolution, I think the balance of evidence tips pretty clearly in the direction that people with low-ish levels would be wise to supplement.

Am I certain that vitamin D is beneficial for people with low-ish levels? Absolutely not! But I claim that’s the best bet given the limits of our knowledge.

The classical view: Boring bone vitamin

Most vitamins are “ingredients” that the body uses to do stuff. Vitamin D is more like a “signal” that the body uses to communicate with itself about what to do.¹ The classical “endocrine” story of vitamin D is that your body uses it to tell your guts to take in more calcium from food. If you don’t get enough vitamin D, then you have calcium problems.

That’s all you really need to know about the classical view. But if you enjoy gawking at biology’s complexity, I recommend this diagram and the following three paragraphs:

Ready for science? OK: Almost all the cells in your body make provitamin D.² Usually, this is all converted to cholesterol, but your skin cells leave some sitting around. When UVB light hits those skin cells, provitamin D is transformed (physically by the light itself) into previtamin D and then (by heat) into vitamin D. This diffuses from the skin cells into blood vessels. There it binds to a protein³ and starts circulating in the blood, where it is joined by vitamin D from food.⁴ Eventually, the liver converts it into more-stable storage vitamin D. It also soaks in and out of fat and muscle tissue, which acts as a slow-release reservoir.

Now, a fun fact: If calcium levels in your blood get too low, then your heart will stop working and you will die. To avoid this, you have parathyroid glands in your neck that sense when calcium is getting low, and release parathyroid hormone into the blood. This tells your bones to release some of their stored calcium. It also tells your kidneys to convert some of the storage vitamin D from your blood into active vitamin D. And when that gets to your guts, they try to absorb more calcium from food.

So what happens if you don’t get enough vitamin D? Well, your body is not going to let calcium levels drop too low, because your body is designed to avoid death. Parathyroid hormone will still get secreted, and it will still tell your bones to scavenge calcium. But without vitamin D, your guts never get the signal to gather extra calcium from food. So the body scavenges a lot of calcium from your bones, and you end up with weak bones, which is bad.

Now here’s the thing: In this story, only active vitamin D actually does anything. The kidneys make this on demand in response to calcium levels, not in response to storage vitamin D levels. General opinion is that as long as the blood has above ~25 nmol/L of storage vitamin D, then the kidneys have no trouble making active vitamin D.⁵ Furthermore, survey data suggests that only ~2% of the population has levels below that threshold. This suggests that for ~98% of people, supplementing vitamin D should do approximately nothing.

The correlation view: Magical mystery cure

Rickets is a terrible disease that involves soft bones, stunted growth, and skeletal deformities. It’s probably been with us since ancient times, but it became common in the West after the industrial revolution. In 1890, a Scottish missionary named Theobald Palm observed that rickets was common in smog-ridden UK cities but almost unheard of in sunny countries with poor sanitation, suggesting sunlight itself was the issue. This contributed to the discovery that rickets could be cured with UV light or cod-liver oil, and eventually the discovery of vitamin D.

In 1941, Apperly noticed that the amount of sunlight in different US states was positively correlated with skin cancer but inversely correlated with overall cancer mortality.⁶ He gave this charming graph:

Apperly never mentions vitamin D, presumably because he thought it was a boring bone vitamin.

Things took off in 1980, when Cedric and Frank Garland published, “Do Sunlight and Vitamin D Reduce the Likelihood of Colon Cancer?” Seemingly unaware of Apperly, they gave a similar, but uglier, graph:

They point out that regional diets (like meat and fiber) didn’t seem to explain this pattern. Instead, they propose a mechanistic story:

    Sunlight
        ↓
    Vitamin D
        ↓
    Adequate calcium in blood
        ↓
    Reduced inflammation of epithelial cells in the colon
        ↓
    Less colon cancer

(It’s always inflammation.) This paper was rejected many times before finally being published. I wish I could find an un-gated copy to link to, because it would have made a magnificent blog post.⁷

Following that paper, there was an explosion of work that found negative correlations between sunlight (or latitude) and other types of cancers as well as blood pressure, diabetes, and multiple sclerosis.

Then people started measuring vitamin D in blood. In 1989, the Garlands and collaborators found blood samples takin in 1974 from 25,000 people. They found that 34 of those people had since gotten colon cancer. They matched these with 67 demographically similar people and measured vitamin D levels in the stored blood samples for all 101 people. Among that group, people with vitamin D levels below 50 nmol/L got colon cancer more than three times as often as people with higher levels.

Again, many similar studies followed. These linked higher vitamin D levels to better outcomes in cardiovascular disease, diabetes, obesity, infectious disease, Parkinson’s, and mood disorders. While results were mixed for non-colorectal cancer incidence, higher vitamin D levels predicted better survival of many cancers. Amazingly, all-cause mortality was roughly 30% lower for those at the 75th percentile of vitamin D levels compared to the 25th.

Vitamin D was looking like a miracle. But how could it do all that stuff if it was just a boring bone vitamin?

Meanwhile in biology

While all these correlations were being discovered, we learned that the body doesn’t just use vitamin D for bone stuff.

In 1969, we discovered the vitamin D receptor that active vitamin D binds to in the gut and bones. And in the 1980s came a shock: Almost all cells in the body have vitamin D receptors. These seem to do different things in different tissues. In the pancreas, they support insulin secretion. In immune cells, they boost antimicrobial peptides and reduce inflammation. In neurons, they influence proliferation and differentiation.

So… What? When calcium drops and the kidneys put out active vitamin D, does every part of the body start doing different unrelated stuff?

In the late 1990s, we cloned the gene for the enzyme that the kidneys use to convert storage vitamin D to active vitamin D. Soon came another shock: This enzyme also exists in tons of other cells, including immune cells, the heart, the skin, the prostate, the breast, and colon. (Another win for the Garlands.)

So it’s not just the kidneys making active vitamin D to trigger the gut. Cells everywhere are making their own active vitamin D and using it to trigger vitamin D receptors in neighboring cells, or even inside the same cell.⁸ This often has little to do with calcium or bones.⁹

So:

1. The kidneys use vitamin D as a boring bone hormone.
2. As long as the blood contains at least ~25 nmol/L of storage vitamin D, the kidneys don’t care. They create the same amount of active vitamin D, in response to calcium levels.
3. But now cells everywhere are using storage vitamin D.
4. To do god-knows-what.
5. With god-knows-what sensitivity to circulating vitamin D levels.

And remember how only active vitamin D does anything? That’s wrong. In the mid-1970s, we learned that storage vitamin D also binds to the vitamin D receptor. The affinity is 100-1000× lower, but have ~1000× more in your blood. So maybe circulating levels of storage vitamin D themselves matter, independently of how much active vitamin D gets made?

If that’s not confusing enough, people also noticed that while active vitamin D levels in the blood aren’t correlated with storage vitamin D (above ~25 nmol/L), levels of parathyroid hormone (the thing your parathyroid glands use to tell your kidneys to make active vitamin D) seem to decline as levels of storage vitamin D rise from ~25 to 50 or 75 nmol/L. Huh?¹⁰

On the one hand, all this makes the idea that vitamin D could be a miracle more plausible. On the other hand, this is getting complicated. And do we really believe that raising your vitamin D levels from the 25th to the 75th percentile could reduce your risk of death from any cause by thirty percent? Maybe we should try giving people vitamin D and see what happens.

Then came the RCTs

There have been many randomized trials. The “right” thing to do in such cases is to look at meta analyses that carefully combine all the data. We’ll get to those. But they conceal a lot of important nuance about what actually happens on the ground during these trials. So let’s start by going over the three main “megatrials”.

The Women’s Health Initiative (WHI) trial came out in 2006 and is still the largest vitamin D trial ever done. This took 36,000 postmenopausal American women and assigned half to take 400 IU daily with calcium and the other half to placebo.¹¹ After seven years, here’s what happened:¹²

Outcome (WHI trial)	Hazard ratio
Fractures	0.97 (0.91 to 1.03)
Cancer	0.97 (0.91 to 1.04)
Cancer mortality	0.90 (0.77 to 1.05)
CVD mortality	0.94 (0.78 to 1.12)
All-cause mortality	0.92 (0.83 to 1.01)
Kidney stones	1.17 (1.02 to 1.34)

(The hazard ratio is the ratio of the rate that something happens in the treatment vs. placebo groups. So, a number less than one suggests a benefit to taking vitamin D, while a number larger than one suggests a harm. The numbers in parentheses show a 95% confidence interval.)

The only statistically significant result was a bad one: Extra kidney stones, likely from the extra calcium.¹³ The other outcomes look vaguely good, but none were statistically significant despite the massive sample size.

This was disappointing. However, the WHI trial had limitations: Many subjects in both the vitamin D and placebo groups were already taking vitamin D, and continued taking it through the trial. The dose of 400 IU was fairly low, many subjects stopped taking their pills, and vitamin D levels didn’t actually change that much. They also measured vitamin D levels in only 6% of subjects, meaning we can’t compare the fates of subjects who started out with low versus high levels.

The next big hope was VITAL, which came out in 2018. They recruited 26,000 older people across the United States, half of them men and 20% Black (and thus far more likely to be vitamin-D deficient). They measured vitamin D levels in most people, and they gave the treatment group 2,000 IU per day.¹⁴ Here were the results after 5.3 years:

Outcome (VITAL trial)	Hazard ratio
Diabetes	0.91 (0.76 to 1.09)
Autoimmune disease	0.78 (0.61 to 0.99)
Cancer	0.96 (0.88 to 1.06)
Cancer mortality	0.83 (0.67 to 1.02)
Major CVD event	0.97 (0.85 to 1.12)
CVD mortality	1.11 (0.88 to 1.40)
All-cause mortality	0.99 (0.87 to 1.12)

Some of the results look good-ish, but cardiovascular mortality was higher in the treatment group, leading to almost no effect on all-cause mortality.¹⁵ More disappointment.

The last megatrial was D-Health, which came out in 2022 based on 21,000 older Australians. Instead of daily supplements, it used a monthly “bolus” dose of 60,000 IU or placebo. Unlike in VITAL, there was no exclusion for people with a history of cardiovascular disease or cancer, and less restriction on how much vitamin D participants could take on their own during the trial.¹⁶ Here were the results after 6 years:

Outcome (D-Health trial)	Hazard ratio
Cancer mortality	1.15 (0.96 to 1.39)
Major CVD event	0.91 (0.81 to 1.01)
CVD mortality	0.96 (0.72 to 1.28)
All-cause mortality	1.04 (0.93 to 1.18)

Now, the treatment group did better in terms of cardiovascular disease, but worse in cancer and worse in all-cause mortality. Even more disappointment.

Just from these three large trials, the main lesson should already be clear: Vitamin D is not a miracle. The correlations were wrong.¹⁷ There is essentially zero remaining hope that taking vitamin D could reduce all-cause mortality by a third.

In this sense, the vitamin D skeptics are definitely right. But what about the other trials? And is there a more subtle lesson?

I made some tables

I wanted a big table that summarized all the major vitamin D RCTs and what they found for different health outcomes. Annoyingly, no such overview appears to exist. So I made my own:¹⁸

Trial	Cancer	Cancer mortality	CVD	CVD mortality	All-cause mortality
Lips 1996					0.92 (0.80 to 1.06)
Trivedi 2003	1.08(0.89 to 1.31)	0.86 (0.61 to 1.21)	0.95 (0.86 to 1.04)	0.86 (0.67 to 1.11)	0.90 (0.77 to 1.07)
WHI 2006	0.98 (0.90 to 1.05)	0.89 (0.77 to 1.03)		0.94 (0.78 to 1.12)	0.92 (0.83 to 1.01)
Lyons 2007					0.99 (0.93 to 1.05)
WFPT 2007					1.00 (0.87 to 1.15)
RECORD 2012	1.04 (0.91 to 1.19)	0.83 (0.55 to 1.26)		0.91 (0.79 to 1.05)	0.93 (0.85 to 1.02)
Lappe 2017	0.70 (0.47 to 1.02)
VITAL 2018	0.96 (0.88 to 1.06)	0.83 (0.67 to 1.02)	0.97 (0.85 to 1.12)	1.11 (0.88 to 1.40)	0.99 (0.87 to 1.12)
ViDA 2018	1.01 (0.81 to 1.25)	0.99 (0.60 to 1.64)	1.02 (0.87 to 1.20)		1.12 (0.79 to 1.58)
D2d 2019	1.07 (0.70 to 1.62)	0.23 (0.03 to 1.86)
DO-HEALTH 2020	0.76 (0.49 to 1.18)		1.37 (0.88 to 2.14)
D-Health 2022		1.15 (0.96 to 1.39)	0.91 (0.81 to 1.01)	0.96 (0.72 to 1.28)	1.04 (0.93 to 1.18)
FIND 2022	1.04 (0.72 to 1.51)	1.14 (0.56 to 2.33)	0.90 (0.62 to 1.32)	0.85 (0.28 to 2.53)	0.81 (0.32 to 2.06)

Lots of the hazard ratios are less than one, suggesting a benefit to supplementation. But lots of them are also higher than one, suggesting a harm. The numbers that are far from one almost always come from smaller trials, which manifest as larger confidence intervals. If you’re interested in the details of how these trials were run, I refer you to more gigantic tables in a footnote.¹⁹

If big tables aren’t your thing, here are some formal meta-analyses, both some recent ones and an older but more comprehensive Cochrane review:

Outcome	Meta analysis	Hazard ratio	Comment
All-cause mortality	Bjelakovic 2014 (Cochrane)	0.96 (0.92 to 0.99)	Trials with low risk of bias.
Cancer mortality	Bjelakovic 2014 (Cochrane)	0.88 (0.78 to 0.98)
Cardiovascular mortality	Bjelakovic 2014 (Cochrane)	0.98 (0.90 to 1.07)
Cancer mortality	Kunzia 2023	0.94 (0.86 to 1.02)
All-cause mortality	Ruiz-García 2023	0.96 (0.91 to 1.00)	Good-quality trials
Cardiovascular mortality	Ruiz-García 2023	1.00 (0.92 to 1.08)	Good-quality trials
All-cause mortality	Cao 2023	0.99 (0.96 to 1.03)

Squinting at the data

There are various ways you could try to squint at these RCT. In almost all of them, most people already had pretty high levels before they started. So why don’t we separate out people who started low? Usually we can’t, because most trials didn’t measure baseline vitamin D.²⁰ And among the trials that did, there are few people with low levels, so the results are noisy and confusing.²¹

Or, you might theorize that benefits would take time to show up, meaning the first couple years just add noise. In some cases—notably VITAL—excluding the first two years seems to help, but in other cases things get worse.²²

Finally, some people speculate that taking gigantic monthly or quarterly “bolus” doses of vitamin D might be dangerous. For example, here’s an enjoyable paragraph from Kunzia et al. in their meta-analysis of vitamin D and cancer mortality:

Our results showing efficacy of daily, but not bolus, vitamin D3 supplementation in reducing cancer mortality are consistent with previous meta-analyses on cancer mortality or all-cause mortality (Guo et al., 2022; Keum et al., 2022; Keum et al., 2019; Zhang et al., 2022; Zhang et al., 2019). However, by including more trials than these previous meta-analyses, we were able to detect statistically significant effect modification by treatment regimen for the first time with statistical significance (pinteraction=0.042). The pattern of intake could be important for a favourable steady state of the bioavailability of the active 1,25 (OH)₂D hormone. Daily administration counteracts the fast excretion of vitamin D from the circulation (Hollis and Wagner, 2013; Keum et al., 2022). Moreover, the enzymes CYP27B1 (converts 25(OH)D to 1,25 (OH)₂D) and CYP24A1 (inactivates 25(OH)D and 1,25(OH)₂D) follow first-order reaction kinetics (Vieth, 2009). This means that doubling the concentration of the precursor doubles the yield of the product, unlike other steroid hormones (e.g., cortisol, oestrogen, testosterone) that follow zero-order kinetics (Vieth, 2020). Intermittent, non-physiologically large vitamin D3 bolus doses may lead to unstable cycling of 25(OH)D and 1,25(OH)₂D levels in blood because the system needs time to adapt to the large doses (Hollis and Wagner, 2013; Keum et al., 2019; Vieth, 2020). In the long run, intermittent bolus regimens at weekly or larger intervals can lead to an up-regulation of countervailing factors (e.g., 24-hydroxylase (CYP24A1), 24,25(OH)2D and fibroblast growth factor 23), all of which ultimately leads to lower synthesis or higher degradation of 1,25(OH)₂D levels (Mazess et al., 2021). Bolus doses, unlike daily doses, failed to reduce C-reactive protein response and actually elevated anti-inflammatory cytokines and doubled the risk of hypercalcemia in previous studies (Krishnan et al., 2012; Martineau et al., 2017; Mazess et al., 2021).

Oh no, up-regulation of fibroblast growth factor 23!²³

I don’t feel like I understand this deeply enough to have any opinion beyond the surface level that the body seems to adapt to large doses of vitamin D in ways that could possibly be bad.²⁴ It seems intuitive that small daily doses would be safer than gigantic monthly doses, but I’m always suspicious of post-hoc mechanistic speculation. Also, if people get enough sun, they can apparently synthesize 10,000-25,000 IU per day, which isn’t that far from the 60,000 IU they got in the D-Health trial. But then again, I think Kunzia et al. are suggesting that the body is designed to adapt to regular exposure to large doses but not intermittent exposure?

Well, if you split up the trails by daily vs. bolus dosing, there’s a decent pattern of daily dosing leading to better results:

Trial (daily dosing)	Cancer mortality	All-cause mortality
Lips 1996		0.92 (0.80 to 1.06)
WHI (Jackson 2006)	0.89 (0.77 to 1.03)	0.92 (0.83 to 1.01)
WFPT (Smith) 2007		1.00 (0.87 to 1.15)
RECORD (Avenell 2012)	0.83 (0.55 to 1.26)	0.93 (0.85 to 1.02)
VITAL (Manson 2018)	0.83 (0.67 to 1.02)	0.99 (0.87 to 1.12)
D2d (Pittas 2019)	0.23 (0.03 to 1.86)
FIND (Virtanen 2022)	1.14 (0.56 to 2.33)	0.81 (0.32 to 2.06)

Trial (bolus dosing)	Cancer mortality	All-cause mortality
Trivedi 2003	0.86 (0.61 to 1.21)	0.90 (0.77 to 1.07)
Lyons 2007		0.99 (0.93 to 1.05)
ViDA (Scragg 2018)	0.99 (0.60 to 1.64)	1.12 (0.79 to 1.58)
D-Health (Neale 2022)	1.15 (0.96 to 1.39)	1.04 (0.93 to 1.18)

If those bolus dosing trials didn’t exist, I’d think this looked pretty good. So, maybe? Or maybe this is a story made up to hallucinate a positive trend. I would lean towards the latter theory, but there are papers like Mazess et al.’s “Vitamin D: Bolus is Bogus”, that suggested this pattern before D-Health’s dismal results came out. There are even some trials that suggest bolus doses don’t even work for treating rickets. So… I’m still not convinced. But maybe.

Aside: There are also many Mendelian randomization studies that look at correlations between health and genes that are related to vitamin D. But I don’t think these provide much information, because the assumptions are shaky and the genes don’t explain much of the variance.²⁵

Where are we?

Still with me? Here’s a summary of the above 5200 words:

• The body uses vitamin D in all sorts of weird and complicated ways. It’s biologically plausible that vitamin D could matter beyond bone stuff with severe deficiency, but there’s no convincing mechanistic evidence that it is.
• Vitamin D levels are strongly correlated with good health outcomes, but RCTs have conclusively shown that most of these correlations are non-causal.
• RCTs haven’t conclusively shown any benefit for anything beyond beyond bone stuff. At best, they’ve given weak evidence for hazard ratios slightly below one.

So you might be wondering: Isn’t that quite weak? Wasn’t this post supposed to be a defense of vitamin D?

The case for supplementing anyway

It’s biologically plausible that vitamin D is good

Everyone agrees that severe vitamin D deficiency (below ~25 nmol/L) is bad. It leads to rickets, adult rickets, osteoporosis, muscle weakness or even—with profound deficiency—to seizures or cardiac arrhythmia. This makes sense, because below ~25 nmol/L, the kidneys have trouble converting storage vitamin D into active vitamin D, meaning you don’t absorb enough calcium from food.

The question is if taking supplement to further raise your levels (say to 50 or 90 nmol/L) is important. We have no mechanistic proof, but it might be true, because many parts of the body use vitamin D as a local signal and because cells are at least somewhat sensitive to circulating storage levels. There’s also this weird thing where parathyroid hormone continues to decline as vitamin D levels rise above ~25 nmol/L even while this seems to make little difference to how much active vitamin D the kidneys make.

Nothing in this world comes without trade-offs. Surely, supplementing vitamin D comes with some downsides. But it seems very unlikely that raising vitamin D levels to a “normal” level would cause more harm than benefit. Especially because…

Humans evolved to have a lot of vitamin D

According to Luxwolda et al.’s 2012 paper, “Traditionally living populations in East Africa have a mean serum 25-hydroxyvitamin D concentration of 115 nmol/L”, traditionally living populations in East Africa have a mean serum 25-hydroxyvitamin D concentration of 115 nmol/L.

Meanwhile, Wahl et al. 2012 try to estimate mean levels around the world today:

This map looks weird because of varying lifestyle, diet, supplementation, and needing to combine fragmented studies. But you get the idea. And remember, those are just averages. So there are lots of people with levels far lower than that in our evolutionary history.

Of course, just the fact that vitamin D levels have dropped doesn’t mean it’s important. Parasitic worm load, wood smoke inhalation, and cousin marriage have also dropped, but we aren’t rushing to restore those to ancestral levels.

But there’s another piece of evidence: After humans migrated out of East Africa, some of them evolved pale skin. Pale skin is bad, because it allows light to destroy folate, which is crucial for pregnancy.²⁶ Evolution doesn’t typically do things that harm fertility, because evolution wants to increase reproductive fitness. The most common explanation is that pale skin allows more UV light to penetrate, and thus allows people to synthesize more vitamin D. If evolution was willing to pay the high “price” of folate destruction for more vitamin D, that seems like good evidence that vitamin D is important.

Some even see contrasts like the Inuits versus Scandinavians as a kind of natural experiment: They lived at similar latitudes, but Inuits ate a diet with vitamin D (fatty fish and whale blubber) and Scandinavians didn’t. The result is that Inuits have darker skin than Scandinavians.²⁷

This is all speculative, and even if true, might be driven by severe deficiency and rickets. Or perhaps prehistoric benefits don’t translate to your lifestyle. But all the people in Luxwolda’s sample in East Africa had levels above ~60 nmol/L. I just don’t see how you can look at this and not see it as providing some suggestive evidence in favor of the idea that raising levels above severe deficiency is unlikely to be harmful, and could be important. So I think the prior is favorable.

What do you expect from vitamin D?

A hazard ratio like HR = 0.96 doesn’t look very impressive. But hold on. Suppose that life expectancy is 80 years and that taking vitamin D every day reduces your risk of all-cause mortality by a factor of HR. A reasonable approximation in rich countries is that this would increase your life expectancy by

    80 × 0.15 × (1-HR) years = 12 × (1-HR) years,

where 0.15 is derived from the entropy of lifespan in rich countries.²⁸ For example, if all-cause mortality had a true hazard ratio of HR = 0.96, then taking vitamin D every day of your life would increase life expectancy by around

    0.48 years.

I claim that this would be a lot. Certainly, if I were about to face my destiny, I would pay a lot of money for an extra 0.48 years. Or, you can calculate that this corresponds to an increase of life expectancy per-vitamin-D-pill of 8.6 minutes.²⁹ A common rule-of-thumb is that smoking a cigarette costs around 11 minutes of life in expectation. If you think HR = 0.96 is trivial, do you also think that smoking one cigarette each day is fine?³⁰

The correlational studies suggested that vitamin D might drop your risk of all-cause mortality by a third. It’s disappointing that the RCTs refuted this. But those correlational studies were crazy. They imply³¹ an increase of life expectancy of around 4 years or around 6.5 cigarettes per day. Could we really believe that you could smoke 6.5 cigarettes, then take a vitamin D pill, and you’re even?

Personally, I think hazard ratios just slightly less than one are the best we can reasonably hope for. But I also think that they would be an excellent return on investment. Arguably, modern human life expectancy comes from stacking lots of modest hazard ratios on top of each other.

What do you expect from vitamin D trials?

Let’s play a game. Let’s hallucinate some numbers for what vitamin D might do, and then simulate what trials would show. Here are the strongest effects I consider plausible for different baseline levels, along with how common those levels are in the United States.

Storage vitamin D (nmol/L)	Hazard ratio	% of population
<30	0.75	5
30-49	0.92	15
50-125	0.98	72.5
>125	1	7.5

Suppose that were real. Now, say we pick 26,000 people at random, and give half of them vitamin D for give yars. Here are the results of a million simulated trials, assuming a baseline mortality risk of 0.7%: ³²

Overall, 9% of trials would find a significant benefit, 63% would find a non-significant benefit, 27% would find a non-significant harm, and 1% would find a significant harm.

If you wanted to have an 80% chance of finding a significant decrease, you’d need to run a trial with something like 570,000 people, almost five times more than in all the above trials combined.³³ If you don’t like my numbers, I’ve put up a page where you can run your own simulations with different ones.

My point is, the results we see in vitamin D RCTs are what we should expect to see if vitamin D had plausible benefits. That’s not proof, of course—just that if you start with realistic expectations, the trials don’t provide much evidence in either direction.

The trials do find slightly helpful numbers

Recent meta-analyses have not consistently found a statistically significant benefit to vitamin D supplementation. But they do suggest a small benefit for cancer mortality and all-cause mortality, and they’re close to being statistically significant. That’s something.

And if you buy the argument that bolus dosing is bad, the results get even better. Kunzia et al. did a meta-analysis of cancer mortality using only trials with daily dosing, and found a hazard ratio of 0.88 (confidence interval 0.78 to 0.98). I’d keep this at arm’s length. The bolus dosing trials might have done worse by random chance, meaning this is a kind of p-hacking. But there’s a reasonable chance (maybe 25-50%) that bolus dosing really is bad, in which case those trials would be convincing evidence.

I actually think it’s surprising that the meta-analyses look as good as they do, because there just aren’t that many people who started out with low vitamin D levels. Only a handful of trials had mean levels below 60 nmol/L, and they all give semi-promising results:³⁴

Trial (low-ish baseline)	Cancer mortality	All-cause mortality
Trivedi 2003	0.86 (0.61 to 1.21)	0.90 (0.77 to 1.07)
WHI (Jackson 2006)	0.89 (0.77 to 1.03)	0.92 (0.83 to 1.01)
Lyons 2007		0.99 (0.93 to 1.05)
RECORD (Avenell 2012)	0.83 (0.55 to 1.26)	0.93 (0.85 to 1.02)

Again, it’s dangerous to dig too deeply looking for these kinds of patterns. If you dig enough, you can always find a way to confirm whatever theory you want. But also again, maybe?

You’re probably already taking vitamin D

You might not personally supplement vitamin D. But for most people reading this, someone else is supplementing it for you.³⁵

Country	Commonly fortified with vitamin D
Australia	Margarine
Belgium	Margarine
Canada	Milk, margarine
Chile	Milk, flour
Ethiopia	Oils
Finland	Milk, yogurt, margarine
Ireland	Margarine, cereal
New Zealand	Margarine (from Australia)
Norway	Margarine, low-fat milk
Pakistan	Oils
Poland	Margarine
Sweden	Milk, yogurt, plant milk, margarine
United Kingdom	Margarine, cereal
United States	Milk, plant milk, margarine, cereal, yogurt

Fortified food is common across the Anglosphere and Scandinavian peninsula. However, it’s rare in the rest of Europe (exceptions: Belgium, Poland) and even-more rare in the rest of the world (exceptions: Chile, Ethiopia, Pakistan).

I think this is important for two reasons. First, vitamin D is oddly self-defeating. There are some places in the world where people care about vitamin D. These are the places that run large trials. But these places also fortify their food and tend to be full of people that already supplement vitamin D. These places also tend to believe it’s unethical to tell the control group not to take vitamin D.

And here’s another question: If you think vitamin D is worthless, are you comfortable recommending removing vitamin D from food? If not, then why is the particular amount of fortification in food now the right one?

Some might argue that the purpose of fortification is to reach the severely deficient, or children, the elderly or pregnant mothers. Maybe! But again, if you could press a button and remove fortification from everyone else, would you feel comfortable pushing that button? Remember, trials don’t test going down from current levels, only going up.

So that’s my story

• Biology and evolution suggest a prior that moderate levels of vitamin D (say 80 nmol/L) are quite possibly better than low levels (like 40 nmol/L) and unlikely to be worse.
• Observational studies say that vitamin D is magical, but those studies are bad and we should ignore them.
• The RCTs show that vitamin D is non-miraculous. But beyond that they don’t provide much information, because they mostly enrolled people with moderate vitamin D levels, meaning plausible effects would require colossal sample sizes to reliably detect.
• What evidence the RCTs do provide points weakly towards a modest benefit.
• If real, that benefit would far exceed the cost of taking vitamin D.
• Therefore, if you have low vitamin D, it seems wise to supplement.

This is all very weak, I know! But sometimes weak evidence is all we’ve got.

I wish we had at least one large trial done in a population with low starting levels. But as far as I can tell, none are underway. In fact, it’s unlikely that there will be any more large trials anytime soon. So weak evidence is how it’s going to be.

And more from the internet.

Today we are excited to announce the Release Candidate of TypeScript 7.0!

If you haven’t been following TypeScript 7.0’s development, this release is significant in that it is built on a completely new foundation. Over the past year, we have been porting the existing TypeScript codebase from TypeScript (as a bootstrapped codebase that compiles to JavaScript) over to Go. With a combination of native code speed and shared memory parallelism, TypeScript 7.0 is often about 10 times faster than TypeScript 6.0.

To get the new compiler, you can just install it from the typescript package on npm, just like with any other release:

npm install -D typescript@rc

The new Go codebase was methodically ported from our existing implementation rather than rewritten from scratch, and its type-checking logic is structurally identical to TypeScript 6.0. This architectural parity ensures the compiler continues to enforce the exact same semantics you already rely on. TypeScript 7.0 has been evaluated against the enormous test suite we’ve built up over the span of a decade, and is already in use in multiple multi-million line-of-code codebases both inside and outside Microsoft. It is highly stable, highly compatible, and ready to be put to the test in your daily workflows and CI pipelines today.

For over a year we’ve been working with many internal Microsoft teams, along with teams at companies like Bloomberg, Canva, Figma, Google, Lattice, Linear, Miro, Notion, Slack, Vanta, Vercel, VoidZero, and more to try out pre-release builds of TypeScript 7.0 on their codebases. The feedback has been overwhelmingly positive, with many teams reporting similar speedups, shaving off a majority of their build times, and enjoying a much more lightweight and fluid editing experience. In turn, we feel confident that the release candidate is in great shape, and we can’t wait for you to try it out.

Using TypeScript 7.0 RC

As mentioned above, to get TypeScript 7.0 RC, you can install it via npm:

npm install -D typescript@rc

From there, you can run tsc just like with any prior version of TypeScript, and you should see the same results as before – just much faster!

> npx tsc --version
Version 7.0.1-rc

To try out the editing experience, you can install the TypeScript Native Preview extension for VS Code. The editor support is rock-solid, and has been widely used by many teams for months now. It’s an easy low-friction way to try TypeScript 7.0 out on your codebase immediately. It uses the same foundation as the command line experience, so you get the same performance improvements in your editor as you do on the command line. Notably, it’s also built on the Language Server Protocol (LSP), making it easy to run in most modern editors or even tools like Copilot CLI.

Running Side-by-Side with TypeScript 6.0

Even though 7.0 RC is close to production-ready, we won’t have a stable programmatic API available until at least several months from now with TypeScript 7.1. Given this, we have made it a priority to ensure TypeScript can be run side-by-side with TypeScript 6.0 for the foreseeable future without any conflicts around “which tsc is which?”

As part of the 6.0/7.0 transition process, we’ve published a new compatibility package, @typescript/typescript6. This package provides an executable named tsc6, so that if needed, you can install TypeScript 7.0 (which ships its own tsc binary) side-by-side without naming conflicts. The new package also re-exports the TypeScript 6.0 API, so that you can use tsc for TypeScript 7, while other tooling can continue to rely on 6.0.

Because some tools like typescript-eslint expect to import from typescript directly via peer dependencies, we recommend achieving this via npm aliases. You should be able to run the following command

npm install -D typescript@npm:@typescript/typescript6

or modify your package.json as follows:

{
  "devDependencies": {
    "typescript": "npm:@typescript/typescript6@^6.0.0",
  }
}

Note that doing this will leave you only with a tsc6 executable. To get 7.0’s tsc, you can add another alias for TypeScript 7 and npx tsc will just work with 7.0:

{
  "devDependencies": {
    "typescript": "npm:@typescript/typescript6@^6.0.0",
    "typescript-7": "npm:typescript@rc",
  }
}

Nightly Releases

TypeScript 7 nightlies are currently still being published under the @typescript/native-preview package on npm, and can be installed via

npm install -D @typescript/native-preview

The binary provided by that package is still named tsgo. Once TypeScript 7 is published with the latest tag on npm, we expect all stable releases, major pre-releases, and nightlies to be published under the typescript package on npm.

Parallelization and Controls

TypeScript 7.0 now performs many steps in parallel, including parsing, type-checking, and emitting. Some of these steps, like parsing and emitting can mostly be done independently across files. As such, parallelization automatically scales well with larger codebases with relatively little overhead. But not every step in a TypeScript build is easily parallelizable.

Checker Parallelization

Other steps, like type-checking, have more complex dependencies across files. Most files end up relying on the same type information from their dependencies and the global scope, and so running type-checkers completely independently would be wasteful – both in computation and memory. On the other hand, type-checking occasionally relies on the relative ordering of information in a program, and so type-checking from scratch must always check the same files in an identical order to ensure the same results.

To enable parallelization while avoiding these pitfalls, TypeScript 7.0 creates a fixed number of type-checker workers with their own view of the world. These type-checking workers may end up duplicating some common work, but given the same input files, they will always divide them identically and produce the same results.

The default number of type-checking workers is 4, but it can be configured with the new --checkers flag. You may find that increasing this number can further speed up builds on larger codebases where typical machines have more CPU cores, but will typically come at the cost of increased memory usage. Likewise, machines with fewer CPU cores and less memory (e.g. CI runners) may want to decrease this number to avoid unnecessary or incidental overhead.

In rare cases, varying the number of --checkers may surface order-dependent results. Specifying a fixed number of checkers across build environments can help ensure everyone is getting the same results, but is up to the discretion of each team.

Project Reference Builder Parallelization

TypeScript 7.0 can parallelize builds within a project, but it can now also build multiple projects at once as well. This behavior can be configured with the new --builders flag, which controls the number of parallel project reference builders that can run at once. This can be particularly helpful for monorepos with many projects.

Like --checkers, increasing the number of builders can speed up builds, but may come at the cost of increased memory usage. It also has a multiplicative effect with --checkers, so it’s important to find the right balance for your machine and codebase. For example, building with --checkers 4 --builders 4 allows up to 16 type-checkers to run at once, which may be excessive.

Unlike --checkers, varying the number of builders should not produce different results; however, building project references is fundamentally bottlenecked by the dependency graph of projects (with the exception of type-checking on codebases that leverage --isolatedDeclarations and separate syntactic declaration file emit).

Single-Threaded Mode

In some cases, it can be helpful to enforce single-threaded operation throughout the compiler. This may be useful for debugging, comparing performance with TypeScript 6 and 7, when orchestrating parallel builds externally, or for running in environments with very limited resources. To enable single-threaded mode, you can use the new --singleThreaded flag. This will not only cap the number of type-checking workers to 1, but also ensure parsing and emitting are done in a single thread.

Improved --watch Mode

Worth calling out is TypeScript 7’s rebuilt --watch mode. --watch is now built on a new foundation derived from the Parcel bundler’s file-watcher that provides efficient and stable cross-platform file watching capabilities.

When our team set out to port our file watching logic, we encountered a few challenges with cross-platform file watching in Go. The standard library doesn’t provide a built-in file watching API, and existing third-party libraries we explored had various issues with stability, performance, cross-platform support, or issues with build tooling integration. We were able to build solutions around polling periodically to check for file changes, and this worked broadly across operating systems; however it was computationally expensive, especially at larger-scale projects with many dependencies in node_modules. Even with dynamic scheduling strategies, we found that pure-polling solutions were too taxing for general use.

For many years, Visual Studio Code has relied on @parcel/watcher, and in recent years TypeScript in VS Code has relied on its file watching capabilities indirectly. While it seemed promising, one of the problems for us with Parcel’s watcher is that it’s written in C++, and in turn requires a full C++ toolchain to build. Given our positive experience with Parcel’s watcher in VS Code, we explored porting it to Go with a few minimal assembly shims to avoid introducing a new toolchain dependency.

The exploration has been a success – what started as a very direct translation from C++ to Go was further refined into idiomatic Go that still passes the ported test suite. The watcher is a self-contained package that has allowed us to keep a clean separation of concerns between what we care to watch and why. We are now seeing significant resource improvements in --watch mode across platforms, and have been hearing positive feedback from earlier users of TypeScript 7.

We’d like to extend our thanks to Devon Govett whose work on Parcel has provided immense benefits to both the Visual Studio Code and TypeScript projects. We hope this port will provide opportunities and insights for the original Parcel watcher codebase over time.

Updates Since 5.x, and New Behaviors from 6.0

TypeScript 7.0 is made to be compatible with TypeScript 6.0’s type-checking and command-line behavior. Practically any TypeScript code that compiles cleanly with TypeScript 6.0 (with the stableTypeOrdering flag on, and without any ignoreDeprecations flag set) should compile identically in TypeScript 7.0.

With that said, TypeScript 7.0 adopts 6.0’s new defaults, and provides hard errors in the face of any flags and constructs deprecated in TypeScript 6.0. This is notable as 6.0 is still relatively new, and many projects will need to adapt to its new behaviors. We encourage developers to adopt TypeScript 6.0 to make the transition to TypeScript 7.0 easier, and you can also read the TypeScript 6.0 release blog post for more details on these deprecations.

At a glance, the notable default changes to configuration are:

• strict is true by default.
• module defaults to esnext.
• target defaults to the current stable ECMAScript version immediately preceding esnext.
• noUncheckedSideEffectImports is true by default.
• libReplacement is false by default.
• stableTypeOrdering is true by default, and cannot be turned off.
• rootDir now defaults to ./, and inner source directories must be explicitly set.
• types now defaults to [], and the old behavior can be restored by setting it to ["*"].

We believe the rootDir and types changes may be the most “surprising” changes, but they can be mitigated easily. Projects where the tsconfig.json sits outside of a directory like src will simply need to include rootDir to preserve the same directory structure.

  {
      "compilerOptions": {
          // ...
+         "rootDir": "./src"
      },
      "include": ["./src"]
  }

For the types change, projects that depend on specific global declarations will need to list them explicitly. For example,

  {
      "compilerOptions": {
          // Explicitly list the @types packages you need (e.g. bun, mocha, jasmine, etc.)
+         "types": ["node", "jest"]
      }
  }

The deprecations that have turned into hard errors with no-op behavior are:

• target: es5 is no longer supported.
• downlevelIteration is no longer supported.
• moduleResolution: node/node10 are no longer supported, with nodenext and bundler being recommended instead.
• module: amd, umd, systemjs, none are no longer supported, with esnext or preserve being recommended in conjunction with bundlers or browser-based module resolution.
• baseUrl is no longer supported, and paths can be updated to be relative to the project root instead of baseUrl.
• moduleResolution: classic is no longer supported, and bundler or nodenext are the recommended replacements.
• esModuleInterop and allowSyntheticDefaultImports cannot be set to false.
• alwaysStrict is assumed to be true and can no longer be set to false.
• The module keyword cannot be used in namespace declarations.
• The asserts keyword cannot be used on imports, and must use the with keyword instead (to align with developments on ECMAScript’s import attribute syntax).
• /// <reference no-default-lib /> directives are no longer respected under skipDefaultLibCheck.
• Command line builds cannot take file paths when the current directory contains a tsconfig.json file unless passed an explicit --ignoreConfig flag.

Template Literal Types Now Preserve Unicode Code Points

TypeScript 7.0 now treats Unicode code points more naturally when inferring from template literal types. For example:

type HeadTail<S> = S extends `${infer Head}${infer Tail}` ? [Head, Tail] : never;

type Result = HeadTail<"😀abc">;
//   ^
// In 7.0: ["😀", "abc"]
// Previously: ["\ud83d", "\ude00abc"]

Previously, TypeScript followed JavaScript’s UTF-16 indexing behavior here and split "😀" into two halves of a surrogate pair (\ud83d and \ude00). That was technically consistent with indexing in JavaScript (e.g. the inferred Head type was equal to "😀abc"[0]), but it usually wasn’t what people intended, and could produce string literal types containing unpaired surrogates that aren’t semantically meaningful.

This is a breaking change for type-level string manipulation that intentionally modeled UTF-16 code units, such as some string Length utilities. In practice, we expect the new behavior to be more useful and less surprising: template literal inference now follows the same intuition as iterating a string with for...of or spreading it with [...str], where "😀" is treated as one unit.

JavaScript Differences

As we ported the existing codebase, we also took the opportunity to revisit how our JavaScript support works.

TypeScript originally supported JavaScript files by using JSDoc comments and recognizing certain code patterns for analysis and type inference. Lots of the time, this was based on popular coding patterns, but occasionally it was based on whatever people might be writing that Closure and the JSDoc doc generating tool might understand. While this approach was helpful for developers with loosely-written JSDoc codebases, it required a number of compromises and special cases to work well, and diverged in a number of ways from TypeScript’s analysis in .ts files.

In TypeScript 7.0, we have reworked our JavaScript support to be more consistent with how we analyze TypeScript files. Some of the differences include:

• Values cannot be used where types are expected – instead, write typeof someValue
• @enum is not specially recognized anymore – create a @typedef on (typeof YourEnumDeclaration)[keyof typeof YourEnumDeclaration].
• A standalone ? is no longer usable as a type – use any instead.
• @class does not make a function a constructor – use a class declaration instead.
• Postfix ! is not supported – just use T.
• Type names must be defined within a @typedef tag (i.e. /** @typedef {T} TypeAliasName */), not adjacent to an identifier (i.e. /** @typedef {T} */ TypeAliasName;).
• Closure-style function syntax (e.g. function(string): void) is no longer supported – use TypeScript shorthands instead (e.g. (s: string) => void).

Additionally, some JavaScript patterns, like aliasing this and reassigning the entirety of a function’s prototype are no longer specially treated.

While some of our JS support is in flux, we have been updating this CHANGES.md file to capture the differences between TypeScript 6.0 and 7.0 in more detail.

Editor Experience

TypeScript 7.0’s performance improvements are not limited to the command line experience – they also extend to the editor experience too. For VS Code users, the TypeScript Native Preview extension provides a seamless way to try out TypeScript 7.0 in your editor, and has seen widespread use. For Visual Studio users, the latest version of the editor will automatically enable TypeScript 7 based on your workspace. Of course, TypeScript 7 should work great in any editor of your choosing. The new foundation is built on the Language Server Protocol (LSP) and is able to leverage multiple threads to serve simultaneous requests as quickly as possible.

Since it first debuted, we’ve added in missing functionality like auto-imports, expandable hovers, inlay hints, code lenses, go-to-source-definition, JSX linked editing and tag completions, and more. Missing features from TypeScript 7.0 beta, such as semantic highlighting, “sort imports”, “remove unused imports”, and more are now in.

Additionally, we’ve continued to drive performance and stability in the past few months. We’ve rebuilt much of our testing and diagnostics infrastructure to make sure the quality bar is high, in which we are able to fuzz-test the language server against the top TypeScript and JavaScript codebases on GitHub. Based on our data insights, we believe TypeScript 7 actually has reduced failing language server commands by over 20x compared to TypeScript 6.0.

This extension respects most of the same configuration settings as the built-in TypeScript extension for Visual Studio Code, along with most of the same features.

The Road to TypeScript 7.0

With TypeScript 7.0 RC now available, our current plan is to release TypeScript 7.0 within the next month, and we will be focusing on release coordination and logistics, reported regressions, and future API capabilities in TypeScript 7.1.

Between now and then, we would especially appreciate feedback from trying TypeScript 7.0 on real projects. If you run into any issues, please let us know on the issue tracker for microsoft/typescript-go so we can make sure the stable release is in great shape.

We also encourage you to share your experience using TypeScript 7.0 and tag @typescriptlang.org on Bluesky or @typescript@fosstodon.org on Mastodon, or @typescript on Twitter.

Our team is incredibly excited for you to try this release out, so try it today and let us know what you think. Happy hacking!

– The TypeScript Team

The post Announcing TypeScript 7.0 RC appeared first on TypeScript.