Strasmore Research
Learn Matt ConnorBy Matt Connor · data as of September 19, 2026 · refreshed weekly

What Is a Liquidity Heatmap? How to Read One

A liquidity heatmap paints resting order size at every price level over time. It needs depth-of-book data, not Level 1, and it only shows displayed orders.

A liquidity heatmap is a chart of the order book over time. Price runs up the vertical axis and time runs left to right; the color of each cell shows how much displayed order size was resting at that price at that moment, with brighter meaning more. Tools such as Bookmap and ATAS popularized the format. It is drawn from depth-of-book updates rather than Level 1 quotes, and that is what puts it out of reach of a free charting app.

What does a liquidity heatmap show?

Picture a standard Level 2 window, the depth-of-market ladder or DOM, as a single column: the current list of prices with resting bid size on one side and resting ask size on the other. A liquidity heatmap replaces those numbers with color and keeps every past column instead of discarding it. Each book update adds a sliver at the right edge and older columns slide left. The result is a grid, time by price, where a large resting order appears as a bright horizontal band that lasts exactly as long as the order does.

Most heatmap tools share a few conventions:

  • The best bid and ask sit at the right edge, with the last traded price drawn as a line through the grid.
  • Color intensity is relative, scaled against the largest size on screen, so a hypothetical 2,000-share order looks bright in a thinly quoted stock and faint in a heavily quoted one.
  • Trades are overlaid as dots sized by the shares that printed, so a reader can see where resting size was actually hit rather than merely displayed.
  • A canceled order simply stops: the band ends and the cell goes dark from that moment on.

All four are renderings of one underlying feed, and that feed decides what the picture can contain.

What data does a liquidity heatmap need?

A heatmap needs the resting size at every price level, every time it changes. That is depth-of-book data, and it comes in two forms. Market-by-price (MBP) feeds publish the aggregate size at each level. Market-by-order (MBO) feeds publish every individual order with its own identifier, so the software can tell that a 5,000-share band is one order rather than fifty small ones. Our comparison of MBO versus MBP order book data walks through what each format carries. Either can drive a heatmap; MBO adds the ability to watch one large order get trimmed, partly filled, pulled, or replaced, and it is the raw material for estimating your own queue position at a level.

Level 1 data is the top of the book only: the best bid and ask, plus the last trade. Painted on a time-by-price grid, that is two thin lines with nothing above or below them. There is no second level to color in. This is the whole answer to "why can't my free charting app show a heatmap?": the app is subscribed to Level 1, often delayed and consolidated, and the picture requires every level. The distinction is spelled out in Level 1 versus Level 2 market data. Depth feeds are also far heavier, which is part of why heatmap platforms are desktop applications tied to a paid data subscription rather than a browser tab.

Here is what that top-of-book stream actually carries, measured for Apple across the most recent session in the data window, in half-hour clock buckets (Eastern Time, extended hours included). The two size columns are the median displayed size at the best bid and at the best ask, each scaled to the session's largest bucket, the same relative scaling a heatmap applies to its colors. This is the single row a Level 1 heatmap could paint.

QueryAAPL top of book by half hour (ET), latest session: NBBO updates and displayed size at the best bid and ask as a share of the peak bucket
32 rows (showing 20)
et_timequote_update_countdisplayed_bid_pct_of_peakdisplayed_ask_pct_of_peak
04:004933333
04:303163367
05:003553367
05:30643367
06:001165033
06:301745033
07:005743333
07:304833367
08:007713367
08:307783367
09:0012133367
09:301268693367
10:00900843367
10:30674563367
11:00637731767
11:30603213367
12:00565613367
12:30462823367
13:00429663367
13:303649833100
The exact SQL behind every number
WITH (
  SELECT max(toDate(sip_timestamp))
  FROM global_markets.cache_stocks_quotes
  WHERE ticker = 'AAPL' AND sip_timestamp >= now() - INTERVAL 7 DAY
) AS last_session
SELECT
  et_time,
  quote_update_count,
  round(100 * median_bid_size / max(median_bid_size) OVER (), 0) AS displayed_bid_pct_of_peak,
  round(100 * median_ask_size / max(median_ask_size) OVER (), 0) AS displayed_ask_pct_of_peak
FROM (
  SELECT
    formatDateTime(toStartOfInterval(toTimeZone(sip_timestamp, 'America/New_York'), INTERVAL 30 MINUTE), '%H:%i') AS et_time,
    count() AS quote_update_count,
    quantileDeterministic(0.5)(toFloat64(bid_size), toUInt64(sip_timestamp)) AS median_bid_size,
    quantileDeterministic(0.5)(toFloat64(ask_size), toUInt64(sip_timestamp)) AS median_ask_size
  FROM global_markets.cache_stocks_quotes
  WHERE ticker = 'AAPL'
    AND sip_timestamp >= now() - INTERVAL 7 DAY
    AND toDate(sip_timestamp) = last_session
    AND bid_price > 0
    AND ask_price > bid_price
    AND bid_size > 0
    AND ask_size > 0
  GROUP BY et_time
)
ORDER BY et_time
Run this yourself

The stream covers 32 half-hour buckets. In the 04:00 bucket, the first with a quote, median displayed size at the best bid stood at 33 percent of its peak bucket and the best ask at 33 percent; in the 19:30 bucket, the last, the bid side measured 42 percent. The count column is how many NBBO updates the feed published in each bucket, a change to the best price or to the size behind it. Every level a heatmap would paint above the ask and below the bid is absent from this stream, and no amount of history fills it in.

Why does the heatmap look different on every venue?

US stocks have no single order book. The same share trades on more than a dozen registered exchanges plus off-exchange venues, and each exchange keeps its own book. A heatmap of the Nasdaq book shows orders resting on Nasdaq and nothing else. The same stock's resting size on NYSE Arca or IEX lives in a separate feed. One exchange's heatmap is one venue's slice of the market, and the slice can be thin in a name that quotes mostly elsewhere.

Consolidated heatmaps exist, but they have to be assembled. The public consolidated feed, the SIP, carries each exchange's best bid and offer rather than its full depth, so there is no ready-made consolidated depth feed. A vendor offering a "consolidated" heatmap subscribes to several direct exchange feeds and merges the levels itself, and the merge is only as complete as the venue list behind it. Our guide to SIP versus direct exchange feeds covers what each one publishes. The format also took hold first in futures, where the E-mini S&P trades on one central book at CME, and in crypto, where each exchange is its own complete market, so one book really is the whole market for that venue.

What a liquidity heatmap cannot show

The most important limit: a heatmap shows displayed liquidity only. Several kinds of interest never appear on it.

  • Hidden orders. Exchanges accept non-displayed limit orders that rest in the book and can execute but are never published in the depth feed. They stay invisible until a trade prints against them.
  • Iceberg orders. An iceberg displays a small slice and holds the rest in reserve. The heatmap paints only the visible slice, and each refill looks like a fresh small order. Our explainer on iceberg orders shows how the reserve is inferred, when it can be, from the trade tape rather than the book.
  • Off-exchange interest. Orders resting in dark pools and parent orders that an algorithm releases in slices are on no exchange book, so they never color a cell.
  • Orders on venues the platform does not subscribe to, as above.

The other limit is time. A resting order is a displayed intention that can be canceled in microseconds, and a heatmap paints intention rather than commitment. A bright band that vanishes just before price reaches it was real while it was displayed and is simply gone now. The grid records both facts. Spoofing, the illegal practice of placing large orders with no intent to execute, exists only where displayed size is visible, and a heatmap makes the cancellation easy to see afterward. The picture is a record of what was shown, which is narrower than what was there.

How to read a liquidity heatmap

Reading a heatmap means describing what the book did, in plain terms, without deciding in advance what it means. The common vocabulary:

  • A wall is a thick, bright horizontal band at one price that persists across time: a large displayed size resting at that level. It says nothing about whether the size will still be there when price arrives.
  • Absorption is price reaching a bright band while trade dots print into it and the band stays bright, or dims and refills, as the trades hit. Displayed size is being consumed and replaced at roughly the pace it is being hit.
  • Pulled liquidity is a band that ends abruptly, often shortly before price would have touched it. No trades printed there. On MBO data the software can show whether that was one cancellation or many.
  • Stepping liquidity is a set of bands that move with price, holding a fixed distance above or below the last trade, so they form diagonal stairs on the grid.

Each of these is an observation about displayed size and trades at a moment in time, and none of them is a forecast of what price does next.

Liquidity heatmap versus liquidation heatmap

A different chart uses the same colors and a confusingly similar name. Sites such as Coinglass publish a "liquidation heatmap" for crypto perpetual futures. That chart does not read the order book at all. It estimates, from open interest and assumed leverage ratios, the prices at which leveraged positions would be force-closed by the exchange, and shades those prices by estimated size. A liquidity heatmap is an observation of orders that exist right now; a liquidation heatmap is a model of positions that might be closed if price reaches a level. A bright band on one means something unrelated to a bright band on the other.

FAQ

Is a liquidity heatmap the same as Level 2 or the DOM?

Same data, different display. A Level 2 window or DOM ladder shows the current resting size at each price as numbers, and only the current state. A liquidity heatmap converts those numbers into color and keeps the history, so past placements, size changes, cancellations, and fills stay on screen as price moves.

Can I get a liquidity heatmap for free?

Rarely for stocks. Drawing one needs a depth-of-book feed, MBP or MBO, which exchanges license for a fee, and free charting apps run on Level 1 or delayed consolidated data with no depth. Some platforms offer a free tier for crypto, where exchanges publish their full book without charge.

Does a liquidity heatmap show iceberg or hidden orders?

No. Both are designed to keep size out of the displayed book. A heatmap paints only the visible slice of an iceberg and nothing for a fully hidden order. Their presence is inferred, when it can be, from trades printing at a price where little or no size was displayed.

Why does my heatmap look different from someone else's?

Most often they are drawn from different venues. Each US exchange keeps its own book, so a heatmap of one exchange's depth shows only that exchange, and platforms that merge several direct feeds differ in which venues they include and how they scale the colors.


Behind every one of these pictures is a plain stream of quotes, each with a timestamp, a price, a size, and a side. The Strasmore terminal lets you ask plain-English questions of the top-of-book quote history for any US stock, a useful way to see how quickly even a single level changes inside one minute.

#liquidity heatmap#order book#depth of book#level 2#bookmap#market data