I pulled the whole CPI-U series to build an inflation calculator. It comes to 1,363 monthly numbers, January 1913 through July 2026, in one tab separated file the government hands out with no key and no account.
One of those 1,363 rows is not a number.
CUUR0000SA0 2025 M10 - X
The dash is the value. The X is a footnote code, and the footnote table sitting in the same directory says what the code means.
X: Data unavailable due to the 2025 lapse in appropriations
October 2025 has no consumer price index. Not a provisional one, not a revised one that landed late. The survey was never collected and nobody has filled it in since. Everything downstream of that series now has a hole in it, and every tool built on top has to decide what to do about the hole.
An Inflation Calculator Is One Division
Every inflation calculator does the same thing. It looks up the price index for the month you started in, looks it up again for the month you asked about, and multiplies your amount by one over the other.
Say $100 in January 2000. The index was 168.800 that month and 333.918 in July 2026. So 100 times 333.918 divided by 168.800, which is $197.82.
That's the whole product. No model, no forecast, no seasonal adjustment, no opinion. Every calculator in this category is arguing over the same table of about fourteen hundred numbers, and the differences between them come down to how they round and what they show you.
Which is why one missing row matters more than it sounds like it should.
When the whole product is a lookup, a row that isn't there is not a rounding problem. It's the product failing to answer, and what it says while it fails is about the only design decision left in the thing.
Where the Series Actually Lives
CPI-U, all items, US city average, not seasonally adjusted, series CUUR0000SA0. That's the same series the government's own calculator runs on, in its own words on its own page: it uses "the Consumer Price Index for All Urban Consumers (CPI-U) U.S. city average series for all items, not seasonally adjusted."
There are two free ways to get it and neither needs a key. The public API answers a plain GET and hands back JSON. The flat file directory hands back the entire series since 1913 as a tab separated table, as long as you send a User-Agent header. Send nothing and you get a polite page explaining that automated retrieval is not welcome, which is fair enough.
I pulled both and compared them before writing a line of the tool. July 2026 is 333.918 in the API and 333.918 in the file. The 2025 annual average is 321.943 in both. Two independent paths agreeing is the cheapest verification there is and it took about a minute, which is a good trade against shipping a transcription error into every answer the page will ever give.
The Row That Is Not a Number
Here is the end of 2025 the way the flat file gives it.
| Month | Index | Footnote |
|---|---|---|
| September 2025 | 324.800 | |
| October 2025 | (blank) | X |
| November 2025 | 324.122 | |
| December 2025 | 324.054 |
Two things stand out. The obvious one is the blank.
The other one is November. It came in below September, which I had to read twice. Prices drifted down across the exact window that has the hole in it, so anybody tempted to draw a straight line from one side to the other would be drawing it through a stretch that wasn't moving in one direction anyway. The tidy assumption and the real behavior disagree, and the only reason I know that is that the two months either side of the hole are sitting right there.
What BLS Did With the Annual Average
This is the part I didn't expect.
BLS publishes an annual average alongside the twelve months of every year. For 2025 that number is 321.943, and in the flat file it carries no footnote at all. No asterisk, no code, nothing marking it as a short year.
So I added up the eleven months that do exist and divided by eleven.
It came to 321.943. Exactly, to three decimals.
The published annual average for 2025 is the mean of the eleven months that were collected, and it sits in the table looking like any other year.
For comparison, had October been filled in by splitting the difference between September and November, the annual average would have landed at 322.153. About two tenths of a point. That sounds like nothing until you push it through a sixty year comparison, where a couple of tenths on the base turns into real money on the answer.
So the agency's own answer to "what do you do with a hole" is to average what you have and not to flag it. I took half of that. Average what you have, and say so.
Three Things a Tool Can Do With a Gap
| Choice | What the user sees | What it costs |
|---|---|---|
| Fill it in from the neighbors | An answer, always | A number nobody published, dressed as one somebody did |
| Slide to the nearest month | An answer for a month they didn't pick | The wrong month, with nothing on screen saying it changed |
| Refuse, and name the reason | No answer for that one month | One extra click, and the truth |
I took the third one. Pick October 2025 on the calculator and it prints the reason in the footnote's own words instead of an amount, and the month stays in the dropdown so that picking it is how you find out.
The first option is the tempting one, because it always answers and a page that always answers feels better than one that sometimes stops. It feels better right up to the afternoon somebody quotes your number in an argument and it turns out to be a number you made up.
The Official Calculator Refuses Too
I loaded the BLS calculator to see how it handles its own missing month. The answer is a banner across the top of the page saying that BLS could not collect October 2025 survey data because of a lapse in appropriations, and that calculations using October 2025 data will not be calculated.
That settles the design question. If the agency that publishes the series won't fill in its own missing month, nothing downstream has any business doing it either.
While I was in there I went looking for a chart on that page, and there isn't one. You type two dates, you get one number. calculator.net does draw a chart, but it's the same picture every time, the yearly inflation rate since 1913, and it has nothing to do with the amount you typed.
A Line With a Gap In It
The chart on my page plots what your amount was worth month by month across whatever span you picked, which means any range touching late 2025 has to cross a month with no value.
Drawing straight through it would be a lie in pixels. So the geometry builds one path per unbroken run of months and starts a fresh one at every hole, and a line under the chart names the month that broke it.
It came to about ten lines of code.
It's also the sort of thing you only build if you read the data before you draw the screen. Start from the mockup instead and the missing month turns up as a rendering bug three days later, and the fix under deadline is always the one that fills it in.
Bundling a Government Series Into a Page
The calculator makes no network calls. Not one. I drove the built page with a headless browser, typed into it, changed both dates, clicked through the examples, and counted every request after load. Zero.
That's possible because the whole series ships inside the page. 1,363 monthly values and 113 annual averages come to 11,605 bytes of source, which is smaller than a thumbnail, and compression takes it well under that.
A hundred and thirteen years of American prices is a small file.
There's a real cost to that. The numbers are frozen at the moment I generated them, so the page can go stale in a way one that calls an API can't. Which brings up the thing this whole category is bad at.
The Stamp Is the Feature
The month the data runs through sits on the page next to the answer, and it goes into every CSV the tool exports. Not in a footer nobody scrolls to.
The reason is a review I read while I was working out whether this tool was worth building. Somebody had paid for an inflation app and left one line about it: it's 2025 and this only goes to 2023.
A calculator with no date on it looks the same whether it was refreshed this morning or abandoned two years ago. You find out when somebody checks your number against a fresher source, usually in public.
A visible stamp turns that into a glance. If it names a month that isn't the most recent release, you know before you copy the answer anywhere.
Rebuilding it is one command that pulls the same public file and writes the table again. That part is deliberately boring.
What $100 Actually Does
Every row here is one division between two published index values, using the annual average for the starting year.
| $100 in | Buys what this buys in July 2026 | Total change |
|---|---|---|
| 1913 | $3,372.91 | +3,272.9% |
| 1950 | $1,385.55 | +1,285.6% |
| 1970 | $860.61 | +760.6% |
| 1980 | $405.24 | +305.2% |
| 2000 | $193.91 | +93.9% |
| 2020 | $129.02 | +29.0% |
The bottom row is the one people argue about. Six years, and a hundred dollars needs to become a hundred and twenty nine.
The Annual Average Is Not January
BLS publishes twelve monthly numbers and one average per year. They are different figures, and picking the wrong one gives a different answer.
That distinction is also where two honest calculators print two different numbers. Take $100 from the 2016 average through to July 2026. My page and calculator.net both say $139.13 and both say the total change is 39.13%, because that part is the same division on the same inputs.
The rate per year comes out at 3.36% there and 3.33% here. Neither is wrong. calculator.net is treating the span as ten flat years. I count an annual average as sitting in the middle of its year, which makes it 121 months instead of 120. Three hundredths of a percent, and the page prints the month count next to the rate so you can see which convention you are reading.
Two Tests That Exist Only Because of the Hole
The lookup hands back a result you have to unwrap rather than a bare number, so no caller can use a missing month by accident. Two tests are in there purely because of October 2025.
One asserts that asking for that month comes back as a failure carrying the reason the agency gave, rather than as a value. The other asserts that the chart leaves a break in the line at a null instead of drawing across it.
Both would pass on any other month without proving a thing, which is the point of writing them against this one. A gap in the input is a case, and a case gets a test.
The other way to learn about it is from a reader.
If You Are Building One
Six things, roughly in this order.
- Pull the series from the primary source, then check it against a second path from the same agency. It takes a minute and it catches a transcription error before it reaches anybody.
- Read the footnote table. The values on their own will not tell you a month is missing on purpose, and the footnote explains it in the publisher's own words, which are better words than yours.
- Decide what a gap does before you draw the UI, because the honest answer changes the return type and the return type changes the screen.
- Put the data month next to the answer, not in the footer.
- Print the arithmetic. The whole product is one division, so showing it costs a line and turns your page into something a person can check against the source.
- Never annualize a span you rounded. Say how many months you counted.
And if you just want the number, the Inflation Calculator is on the site now. Any amount, any two months back to 1913, with the chart and the division printed under the answer. No account, and nothing you type leaves the tab, because there's nowhere for it to go.
Last updated: September 9, 2026 | Reading time: 11 minutes
Written by Evgeniy Poznyak, who spent an afternoon proving that an average was the mean of eleven numbers.