Binance Public Data: SPOT and Futures historical files without an API key

SPOT data comes from three API endpoints, with microsecond timestamps from January 1, 2025

The project documents three SPOT data types. AggTrades records come from /api/v3/aggTrades and store eight columns: aggregate tradeId, price, quantity, first tradeId, last tradeId, timestamp, whether the buyer was the maker, and whether the trade was the best price match. Trades records from /api/v3/historicalTrades carry seven columns: trade Id, price, qty, quoteQty, time, isBuyerMaker and isBestMatch. Klines from /api/v3/klines contain twelve columns, covering open time, open, high, low, close, volume, close time, quote asset volume, number of trades, taker buy base asset volume, taker buy quote asset volume, and a final column the schema marks as ignore.

A time precision boundary applies to SPOT only. Any SPOT file dated 2025 or later stores timestamps in microseconds; files from before that date use milliseconds. The README documents this as a change taking effect January 1, 2025. Futures files carry no parallel note, so a parser that reads both categories together has to detect which precision to expect based on the SPOT file date. Code written before that boundary was introduced and still consuming recent SPOT files will parse the timestamps incorrectly without an update.

USD-M and COIN-M Futures use different column layouts for trades and klines

Futures data covers two categories: USD-M Futures, served by /fapi/v1/ endpoints, and COIN-M Futures, served by /dapi/v1/ endpoints. The aggTrades schemas match each other and share six of SPOT's eight columns, dropping the best price match flag. Both Futures aggTrades tables carry seven columns: aggregate tradeId, price, quantity, first tradeId, last tradeId, timestamp and whether the buyer was the maker.

Klines differ more between the two markets. USD-M klines follow the same twelve-column layout as SPOT klines. COIN-M klines replace "quote asset volume" at column position 8 with "base asset volume", and swap "taker buy base asset volume" and "taker buy quote asset volume" for "taker buy volume" and "taker buy base asset volume". Both still carry "number of trades" at position 9.

The trade schema is where the split between USD-M and COIN-M is easiest to overlook. USD-M trades use quoteQty as one of the columns. COIN-M trades use baseQty instead, denominating the value in the base asset. Writing a single parser that reads both markets without branching on market type will misread those columns for one of the two.

URL structure on data.binance.vision follows market type, interval, symbol and date

All files live on data.binance.vision and follow a path pattern: /data/, then market type, then daily or monthly, then data type, then symbol, then interval (for klines), then a filename. The README shows two commands for the same file:

# Examples for downloading monthly Spot 1h lines for "ADABKRW" symbol.
curl -s "https://data.binance.vision/data/spot/monthly/klines/ADABKRW/1h/ADABKRW-1h-2020-08.zip" -o ADABKRW-1h-2020-08.zip
wget "https://data.binance.vision/data/spot/monthly/klines/ADABKRW/1h/ADABKRW-1h-2020-08.zip"

The filename encodes symbol, interval, year and month. Daily files follow the same structure with daily replacing monthly and the filename ending in the date rather than year-month.

Coverage is complete across symbols, and the publication timing is fixed. A daily file for a given symbol becomes available one day after that trading day closes; a monthly file for a given month appears on the first Monday of the following month. The shell/fetch-all-trading-pairs.sh script retrieves the current set of active symbols for both Spot and Futures, which matters for any pipeline targeting the full archive rather than a fixed list of pairs.

The 1mo interval name avoids a collision with 1m on case-insensitive file systems

All kline intervals are present in the archive: 1s, 1m, 3m, 5m, 15m, 30m, 1h, 2h, 4h, 6h, 8h, 12h, 1d, 3d, 1w, and 1mo. The monthly interval uses the name 1mo rather than 1M. On a case-insensitive file system, 1m and 1M map to the same directory entry, which would cause a monthly klines folder to collide with the one-minute folder. Using 1mo removes that ambiguity entirely.

Any script constructing download URLs must use 1mo in the interval position; using 1M will fail to locate the file. The 1s interval is the finest granularity listed for SPOT klines. The Futures sections of the README cover klines without specifying which intervals are available for each market, so checking data.binance.vision directly is a necessary step before building any Futures interval loop.

sha256sum on Linux and shasum on macOS verify each downloaded zip against its companion file

A .CHECKSUM companion sits at the same path on data.binance.vision as the zip it validates. Verification differs by operating system. On Linux:

sha256sum -c BNBUSDT-1m-2021-01.zip.CHECKSUM

On macOS:

shasum -a 256 -c BNBUSDT-1m-2021-01.zip.CHECKSUM

Both commands compare the downloaded zip against the hash in the .CHECKSUM file. For automated pipelines, skipping this step means a silently corrupted or outdated file enters the dataset without detection. Files in the archive can receive corrections post-publication when errors surface. Two such corrections have occurred: a kline data fix published on 2022-08-08 and an aggTrades correction on 2022-04-21 that aligned data to a Spot aggregate trade API change from 2022-04-12.

A local file cached before 2022-08-08 may differ from what the archive now holds for the same kline file. Running the checksum verification after re-downloading is the only reliable way to confirm a local copy is current.

python/ and shell/ folders hold helper scripts, and one fetches all active trading pairs

Scripts in python/ and shell/ wrap the download process, but the README names their contents only at a high level. Examining the repository directly is needed to see what each script handles in terms of data type, market and date range.

The one script named explicitly in the README is shell/fetch-all-trading-pairs.sh. Running it prints the full list of symbols currently active across Spot and Futures. That matters for any pipeline targeting the complete archive rather than a fixed set of pairs, since the list of active symbols changes as instruments are added or removed.

Direct curl and wget calls are the first approach the README demonstrates. The scripts sit behind them as more convenient options for larger downloads. Any pipeline that goes beyond those basic examples needs to inspect the python/ and shell/ folders to understand what arguments each script accepts.

TERMS_AND_CONDITIONS.md governs the dataset; the MIT license covers only the repository code

The repository carries a MIT license declaration in its README. The top-level files are .gitignore, README.md, TERMS_AND_CONDITIONS.md, python/, shell/, and updates/. There is no LICENSE file in that list, so anyone who needs the license text for a dependency scan or compliance check should inspect the repository directly to see whether it exists elsewhere.

The README draws a clear line between two layers. MIT applies to the scripts in the repository. What a consumer may do with the CSV and zip files they download is a separate question; TERMS_AND_CONDITIONS.md sets those boundaries, and the two documents govern different things.

Reading TERMS_AND_CONDITIONS.md before building a production pipeline is the right order of operations. Treating MIT as coverage for the data itself is an error the separation between the two documents is designed to prevent.

Two documented archive corrections affect kline and aggTrade files from 2022

An update log in the README is described there as exhaustive, listing every correction applied to the archive since its creation. Two entries appear. The first, published 2022-08-08, fixed inconsistent kline data. The second, published 2022-04-21, aligned aggregate trade data to match a change in the Spot aggregate trade API that Binance introduced on 2022-04-12. Each entry names a zip file under the updates/ folder containing the corrected files along with their checksums.

The word "exhaustive" signals that no undocumented replacements have occurred. For most users downloading current data, these 2022 corrections are past events. They become relevant when a pipeline contains locally cached files from before those dates and has never re-verified them against the current checksums.

The last push to the repository was on 2026-09-30, and the repository is not archived. No GitHub releases exist, so there is no versioned artifact to pin when tracking changes to the helper scripts over time.

Editorial conclusion

Binance Public Data suits researchers and algorithmic traders who need historical klines, trades or aggTrades for SPOT, USD-M Futures or COIN-M Futures without calling an API. Skip it when your requirements include order book depth snapshots, funding rates, or any data type the README does not describe. Before building a pipeline, read TERMS_AND_CONDITIONS.md to confirm your use case is permitted, account for the microsecond timestamp in SPOT data from January 1, 2025 onward, and run sha256sum or shasum against each downloaded file's .CHECKSUM companion to catch any archive replacement that predates your local copy.

Frequently asked questions

Official sources

1. binance/binance-public-data on GitHub
2. Issues
3. README