The AI water footprint calculator above estimates the data-centre water and electricity associated with a given amount of AI use. It is built differently from most calculators on this subject, and deliberately so. Every intensity factor is an input you control rather than a constant baked into the code, the source and meaning of each default is stated on the field itself, and the tool always shows what a second published method would give for the same usage so the disagreement is visible rather than hidden.
Arb Digital publishes free calculators, and this one comes with a warning attached. Published estimates of the water behind a single AI query differ by more than an order of magnitude, and they differ for real reasons: cooling design, climate, season, time of day, the electricity mix of the local grid, and what the estimate chooses to count. Anyone presenting a single confident figure has quietly picked one set of assumptions. This page makes you pick them instead.
What This AI Water Footprint Calculator Does
It offers two routes to the same quantity. The first builds the estimate up from energy: multiply requests by watt-hours per request to get electricity, then multiply electricity by two separate water intensities — the on-site water a data centre evaporates for cooling, and the off-site water consumed generating that electricity. The second applies a single headline millilitres-per-request figure directly, which is how most published summaries express it.
Both are legitimate and they are not equivalent. The energy-first route makes every assumption inspectable and lets you model a specific site or grid. The headline route captures whatever was in the original study's assumptions and hides them. Running both on the same usage and comparing is the most useful thing this page does, which is why the fourth result tile always shows the method you did not select.
The bars break the energy-first result into its on-site and off-site halves. That split matters because they are not fungible: on-site water is usually withdrawn and evaporated at the data centre's own location, often in a place chosen for cheap land and power rather than water abundance, while off-site water is spread across wherever the generating capacity sits.
How to Use It
- Enter how many requests you make a day and pick a rough request type. The type only prefills the energy field with a different placeholder.
- Replace the energy figure with the best number you can find for the model you actually use. This is the input the whole estimate hangs on.
- Set the on-site water intensity to match the cooling design you are modelling. A closed-loop or air-cooled facility approaches zero; an evaporative-cooled one in a hot climate is at the high end.
- Set the off-site figure from the grid mix where the compute runs. Thermal generation consumes far more water per kilowatt-hour than wind or solar.
- Compare the headline with the fourth tile. If they are far apart, report the range and say which assumptions produced each end of it.
The Formulas and How They Are Calculated
The energy-first method is water = requests × energy per request × (WUE + EWIF), where WUE is water usage effectiveness in litres per kilowatt-hour of data-centre electricity, and EWIF is the water consumed per kilowatt-hour of electricity generated. Both terms have the same units, so they simply add.
Work the default. Fifty requests a day at 0.30 watt-hours is 15 watt-hours, or 0.015 kilowatt-hours a day. Multiplying by a WUE of 1.0 gives 0.015 litres of on-site water and multiplying by an EWIF of 3.0 gives 0.045 litres off-site, a total of 0.060 litres a day and about 21.9 litres a year, on 5.5 kilowatt-hours of electricity.
The simple method is water = requests × millilitres per request. The same fifty requests at 16.7 mL each is 835 mL a day and about 305 litres a year — fourteen times the energy-first figure. Neither is wrong. They encode different assumptions about how much energy a request uses and how thirsty the facility running it is, and the gap between them is the honest measure of how uncertain this whole area currently is.
Where the Default Numbers Come From, and What They Actually Measured
The millilitres-per-request default traces to a 2023 preprint, Making AI Less "Thirsty": Uncovering and Addressing the Secret Water Footprint of AI Models by Li and colleagues. It is the paper behind almost every headline on this subject. What it did was model water consumption from publicly available data on data-centre cooling and electricity generation, estimating among other things that a conversation of roughly ten to fifty responses could be associated with something like half a litre of water.
Three qualifications on that figure matter and are usually dropped. It is a modelled estimate built on public disclosures, not a metered measurement of a specific service. The authors themselves emphasise that it varies substantially by location and by time — the same workload in a cool climate at night is a very different number from the same workload in a hot climate at midday. And it was framed around models of that period; the energy cost per response for a given task has moved considerably since, in both directions depending on whether the model is smaller and better optimised or larger and doing more reasoning.
The energy side is weaker still. Providers do not publish per-request energy consumption in any comparable way, so public estimates are reverse-engineered from hardware specifications, reported fleet energy, or benchmark measurements on open models. Figures circulating for a single chat response range from well under a tenth of a watt-hour to several watt-hours, a spread of two orders of magnitude that reflects genuine differences in model size, response length, batching efficiency and hardware generation, not merely sloppy estimation. The International Energy Agency's tracking of data centres and networks is the most useful sector-level anchor, and it works at the level of total sector electricity rather than per query for exactly this reason.
Why On-Site and Off-Site Water Are Different Problems
A data centre consumes water twice over. On site, evaporative cooling turns liquid water into vapour to shed heat; that water leaves the local system. Off site, generating the electricity the facility draws consumes water too — thermal plants evaporate cooling water, and hydroelectric reservoirs lose water to evaporation from their surface.
The two respond to completely different interventions. On-site consumption falls with closed-loop cooling, air cooling, or simply siting the facility somewhere cool, at the cost of higher electricity use — which raises the off-site figure. That trade-off is real and it is why a single combined number can conceal a facility that has optimised hard on one side while worsening the other. Off-site consumption falls with a cleaner grid mix, because wind and solar generation consume almost no water in operation, which is a decision largely outside any individual operator's control. The US Energy Information Administration's overview of electricity use gives the sectoral context for where that generation goes.
There is a third distinction that the intensity factors on this page do not capture at all: withdrawal versus consumption. Withdrawn water is taken from a source and largely returned, warmer; consumed water is evaporated and does not come back to that watershed. The figures here are consumption figures. A study quoting withdrawal will produce a much larger number for the same facility, and comparing one against the other is meaningless. Whenever you see two water statistics that disagree wildly, check this first.
What This Estimate Cannot Tell You
Three limits are worth stating plainly. First, this is inference use only. Training a large model is a separate, large, one-off cost that is amortised across every subsequent query in ways no public figure pins down reliably, so the per-request numbers here neither include it nor allocate it.
Second, marginal use is not average use. Your fifty queries a day do not cause a data centre to be built, and switching them off would not cause one to be decommissioned. The numbers here are an average allocation of a shared system's footprint, which is the right frame for understanding scale and the wrong frame for reasoning about the consequence of one person's decision.
Third, water is local. A litre evaporated in a water-stressed basin is not equivalent to a litre evaporated where water is abundant, and no litre-count captures that. Serious water accounting weights consumption by local scarcity, which is why organisations doing this properly report a water-stress-weighted figure alongside the raw volume. For the energy side of the same question, our GPU cost calculator prices compute in dollars, the electricity bill calculator converts kilowatt-hours into money, and the energy converter handles the unit changes between them.
Putting the Number in Proportion
Whatever figure this page returns, it belongs next to some context. Domestic water use in developed economies runs to hundreds of litres per person per day, and the water embedded in food production is larger again by a wide margin. An individual's AI use, on any of the published intensity factors, sits well below either. That is not an argument that it does not matter — it is an argument that individual-level framing is the wrong lens.
The figure that does matter is aggregate and it is growing fast. Data-centre electricity demand is rising sharply, and where that capacity is built determines whether the associated water consumption lands in a stressed basin or not. Siting, cooling design and grid mix are the variables with leverage, and all three are decisions made by operators and regulators rather than by users.
If you want to compare this against other everyday footprints on a consistent basis, our water usage calculator covers household consumption, the flight carbon footprint calculator handles travel, and the crypto carbon footprint calculator covers the other compute-heavy activity people usually ask about in the same breath.
Arb Digital publishes hundreds of free calculators across chemistry, maths, finance and marketing — no sign-up, no limits. If something you need is missing, tell us and we will look at building it.
Browse All Free Tools Suggest a ToolCommon Mistakes to Avoid
- Quoting one figure as fact — published estimates differ by more than tenfold on the same usage, so the honest output is a range with its assumptions attached.
- Mixing withdrawal with consumption — withdrawn water is largely returned to the source and consumed water is not, and the two produce wildly different numbers for the same facility.
- Ignoring the on-site and off-site trade-off — cutting evaporative cooling raises electricity use, which raises the off-site water figure. Only the total is comparable.
- Applying an inference figure to training — training is a separate one-off cost, and per-request numbers neither include it nor allocate it.
- Treating an average allocation as a marginal effect — these numbers describe a share of a shared system, not the consequence of one person's next query.
Related Free Tools From Arb Digital
Price the compute side with the GPU cost calculator, turn kilowatt-hours into money with the electricity bill calculator, and switch between energy units using the energy converter. For everyday comparisons, the water usage calculator covers household consumption, the flight carbon footprint calculator covers travel, and the crypto carbon footprint calculator covers the other compute-heavy activity. The full free online tools hub lists everything else.
Frequently Asked Questions
There is no single agreed figure. Published estimates for a chat-sized request span more than an order of magnitude, because they depend on model size, response length, cooling design, climate, season and the local electricity mix. This page asks you to choose the intensity factor rather than presenting one as fact.
It is one reading of a widely cited 2023 preprint by Li and colleagues, which modelled water consumption from public data and estimated that a conversation of roughly ten to fifty responses could be associated with around half a litre. The authors stress it varies substantially with location and time.
They encode different assumptions. The energy-first route needs a watt-hours-per-request figure and two water intensities you supply, while the headline route carries whatever assumptions its original study made. With the defaults here they differ by about fourteen times, which is a fair reflection of the uncertainty.
WUE is the litres of water a data centre consumes per kilowatt-hour of electricity it uses, almost all of it evaporated in cooling. Reported values run from near zero for closed-loop or air-cooled facilities to around two for evaporative cooling in hot climates.
Generating electricity consumes water too, mainly through evaporation at thermal power plants and from hydroelectric reservoirs. That off-site consumption is often larger than the data centre's own cooling water, and it depends on the grid mix rather than on the facility.
No. Training is a separate one-off cost that is amortised across all subsequent use in ways no public figure pins down reliably. These numbers cover inference — the requests you actually make — only.
No, and confusing them is a common source of wildly different published numbers. Withdrawn water is taken from a source and largely returned, while consumed water is evaporated and leaves the watershed. The figures here are consumption figures.
On any published intensity factor it sits far below household water use and far below the water embedded in food. The figure that matters is aggregate, and the variables with real leverage are where data centres are sited, how they are cooled and what grid they draw on.
This calculator produces order-of-magnitude estimates from intensity factors that you choose, and published values for those factors disagree by more than tenfold. It is provided for education and general reference and is not an environmental audit, a corporate reporting instrument, or a basis for any claim about a specific provider or facility.
