OHLCV stands for Open, High, Low, Close, Volume — the five values that summarise a market's price action and traded volume within a fixed time bucket (a one-minute bar, a one-hour bar, a daily bar, etc.). It is the most widely-used compressed format for historical price data: every charting library, almost every backtester, and most exchange APIs return data as OHLCV bars.
What each value means
| Field | Meaning |
|---|---|
| Open | The price of the first trade inside the bucket. |
| High | The highest traded price during the bucket. |
| Low | The lowest traded price during the bucket. |
| Close | The price of the last trade inside the bucket. |
| Volume | The total quantity traded (in base units) during the bucket. |
Combined with the bucket's start timestamp, OHLCV gives you everything needed to draw a candlestick and compute most price-based indicators (moving averages, RSI, Bollinger Bands, ATR, etc.).
OHLCV vs OHLC vs tick data
- Tick data is one row per trade. Highest fidelity, largest size — a busy BTC/USDT pair generates 50-200 MB per day per exchange.
- OHLC is OHLCV minus the volume column. Older systems and pure price-action charts sometimes use it.
- OHLCV is OHLC plus traded volume. Standard format on every modern exchange API.
- OHLCVT sometimes appears, where T = trade-count inside the bar. Useful when you want a proxy for activity that volume alone does not capture (e.g., distinguishing 1 large trade from 1,000 small ones).
Common bar intervals
Every venue exposes its own subset, but the de-facto standard set across crypto exchanges is: 1m, 3m, 5m, 15m, 30m, 1h, 2h, 4h, 6h, 8h, 12h, 1d, 3d, 1w, 1M.
The two things OHLCV cannot tell you
OHLCV is a lossy compression. Two facts get destroyed by aggregation:
- Order of events inside the bar. You see that the high and low both happened, but not in what sequence. A bar where the price went low-then-high is indistinguishable from one where it went high-then-low. For any strategy where intra-bar path matters (stop-loss simulation, mean reversion entries), OHLCV is not enough.
- Order book depth. Volume tells you what traded. It does not tell you what was offered. A 1,000 BTC bar with $50M of bids waiting at the close behaves very differently from one with $500k of bids waiting. For execution analysis, market-impact modelling, or anything microstructure-related, you need the L2 order book — not OHLCV.
When to use OHLCV — and when not to
Use OHLCV when: charting, computing technical indicators, training daily/hourly factor models, doing rough-cut backtests of trend or carry strategies, and storing long histories cheaply.
Use tick or L2 data instead when: simulating execution and slippage, market-making research, latency-sensitive backtests, or anything where intra-bar sequence matters. Microverse Systems' historical replay serves full L2 order book deltas at the original exchange timestamps so the bar-aggregation problem disappears entirely — you reconstruct OHLCV from ticks, not the other way around.
OHLCV in JSON: the de-facto format
[ [1714694400000, 64200.5, 64412.0, 64180.1, 64320.0, 142.83], [1714694460000, 64320.0, 64355.0, 64290.0, 64340.5, 88.10], [1714694520000, 64340.5, 64380.0, 64310.0, 64315.0, 95.42] ] // Each row: [timestamp_ms, open, high, low, close, volume]
This is the format used by Binance, OKX, and most exchanges that follow the CCXT-compatible convention. Coinbase and Kraken use slightly different orderings, so always read the docs for your specific feed.
This article is part of the Microverse Systems glossary — practical reference for institutional crypto market microstructure.