A list of all ETFs in CSV format is a delimited text file with one row per exchange-traded fund and columns carrying that fund's identifiers and descriptive attributes: ticker, exchange code, fund name, issuer, asset class, listing status and an as-of date. That definition is deliberately narrow, because the hard part of the problem is not assembling the rows. It is deciding which columns the file must carry, how often each one goes stale, and whether the file you downloaded still describes the market as it exists today.
Most pages that rank for this query hand you a ticker list and stop. A ticker list is the easy part. What follows is a field-level specification, an honest assessment of where files of this kind come from, and an acceptance test you can automate before a model reads a single row.
What a "list of all ETFs CSV" actually is
Three different artefacts get called "a list of all ETFs," and conflating them is the most common cause of a project stalling two weeks in. They differ in row count by roughly three orders of magnitude and in cost by considerably more.
| Artefact | Grain | Typical columns | What it answers |
|---|---|---|---|
| Ticker symbol list | One row per fund | Ticker, name | What exists |
| Fund master | One row per fund | Identifiers, issuer, asset class, leverage, status, as-of date | What each fund is |
| Holdings file | One row per fund per position | Fund ticker, security identifier, weight, shares, market value | What each fund owns |
A ticker symbol list is the artefact most free downloads actually contain, which is precisely why they are free. Two columns of public, uncopyrightable fact cost nothing to publish and almost nothing to maintain, and they answer only the shallowest question anyone asks of ETF data.
A fund master adds the attributes that let you filter, group and reconcile. A holdings file is a different shape of data entirely: it is one-to-many, it changes daily, and it is where the real sourcing cost sits.
If you are reading this because a portfolio system needs to know what 400 funds hold, the ticker list is step zero of about six.
Which columns make an ETF CSV usable, and which are decoration
A usable ETF CSV carries, at minimum, a venue-qualified identifier, a stable cross-venue identifier, the attributes that change fund behaviour, and an as-of date. Everything else is convenience. The table below gives the specification and, for each field, the failure it prevents.
| Column | Why it exists | What breaks without it |
|---|---|---|
| Local ticker | Human-readable key | Nothing on its own, but it is not unique across venues |
| Exchange code (MIC or vendor code) | Qualifies the ticker to a venue | Cross-listed funds collide; your join silently picks one at random |
| ISIN or CUSIP | Settlement and custodian reconciliation | Positions from the custodian will not match positions in your model |
| Bloomberg FIGI | Stable mapping across venues and corporate actions | Re-ticker events break the historical join |
| Fund name | Disclosure, display, sanity checks | Nothing reconciles against a prospectus |
| Issuer | Concentration and counterparty grouping | Issuer-level exposure limits cannot be enforced |
| Asset class | Universe filtering | Bond and commodity funds leak into an equity screen |
| Leverage factor | Position sizing | A 3x fund is sized as if it were 1x |
| Inverse flag | Direction of exposure | Net exposure calculations invert on part of the book |
| Holdings count | Completeness check on the holdings join | You cannot tell a truncated holdings file from a concentrated fund |
| Listing status | Survivorship control | Closed funds vanish from history without a trace |
| As-of date | Freshness and point-in-time reproducibility | No backtest built on the file is reproducible |
The two fields teams most often omit are listing status and the as-of date, and they are the two that cause the most expensive failures. A file without an as-of date cannot be used to reconstruct what you knew on a given day, which quietly disqualifies it from anything a compliance review will look at later.
AmericanETP includes Bloomberg FIGIs directly in the holdings files, so the mapping from a fund's positions to a cross-venue identifier does not require a second vendor. A separate fundamentals file carries the ETF description, leverage and holdings counts, which covers the behavioural attributes in the table above.
Identifier plumbing matters beyond the ETF wrapper itself. The same discipline, matching a line item to a stable identifier before any arithmetic runs, is what makes a weighted calculation defensible, as covered in the market cap formula and how float and FIGI feed it.
Where can you download a list of all ETFs as CSV?
There are five realistic source categories, and they trade off against each other on coverage, field depth, update cadence and redistribution rights. No single free source wins on more than two of those four.
Exchange listing directories. Listing venues publish their own listed products. Coverage is authoritative for that venue and incomplete for the market, because a US-traded ETF universe spans several venues. Field depth is usually thin: identifiers and names, rarely leverage or holdings counts.
Individual issuer sites. Every large ETF issuer publishes its own funds, often with same-day holdings. This is the highest-quality free source for any single fund family and the worst possible way to build a market-wide file, because you are maintaining dozens of separate scrapers against dozens of separately changing page layouts.
Aggregator web tables. Sites such as stockanalysis.com and etfdb.com publish browsable ETF tables. Whether a given table exports to CSV, how many rows it returns, and what its terms permit are properties of those sites on the day you look, and we are not reproducing those details from memory here. Check the export control and the terms of use page yourself before you build anything on top.
Community scrapers. An ETFs.csv file on GitHub, or a scraper posted to Reddit against an aggregator, will get you rows quickly. The costs are structural rather than incidental: there is no as-of date you can trust, no notification when the upstream layout changes, no listing-status column, and no licence for commercial redistribution.
Subscription data providers. AmericanETP, ETF Global, FactSet, Refinitiv, Morningstar and S&P Global Market Intelligence all sell ETF reference and holdings data, and they are not substitutes for one another. The useful way to separate them is by what the rest of the platform is for.
FactSet, Refinitiv and S&P Global Market Intelligence sell ETF data as one component of a broad financial data platform, which is the right shape if you also need company fundamentals, estimates, filings and pricing from the same contract and the same identifier spine. Morningstar's public positioning centres on fund research and ratings alongside the underlying data. ETF Global positions specifically around ETF analytics. AmericanETP sells holdings files and index membership as the product itself, with published pricing and FTP delivery, which suits a team that needs the files and not the terminal. We have not verified current pricing, coverage counts or delivery options for any of the other five providers here, and you should take those from their own pages rather than from a blog post. The positioning differences between two of them are examined in more detail in Refinitiv versus Morningstar.
Why a scraped ETF list goes stale faster than you expect
An ETF universe churns through launches, closures, ticker reassignments, listing venue moves, share class changes and leverage resets, and a scraped snapshot records none of those events: it records only the state at the moment of the scrape. Three months later the file is not slightly wrong, it is wrong in a direction.
The direction is the problem. A snapshot taken in July and used in October has silently dropped every fund that closed in between, and it has no row for anything launched since. Run a backtest over that universe and every closed fund, by definition a fund that performed badly enough or gathered too few assets to survive, is absent from the sample.
That is survivorship bias, and in ETF data it is sharper than in single-stock data because fund closures cluster in exactly the strategies that disappointed. A thematic universe reconstructed from today's list will contain the themes that worked.
The defence is a point-in-time archive rather than a better scraper. AmericanETP keeps archived holdings datafiles back to July 2009, so a universe can be reconstructed as it stood on a given date rather than as it stands now, and updates run twice daily with a primary delivery at 6pm EST and a secondary run around noon EST. For teams tracking what moved rather than what exists, diffing two dated files from that archive isolates the additions and removals without requiring a separate change history to be maintained by hand.
From a ticker list to all ETF holdings
Joining a fund list to holdings changes the shape of the data from one row per fund to one row per fund per position, which is where row counts go from thousands to millions and where most free sources stop being an option. This is the step every directory page skips.
Four structural issues appear immediately. Weights within a fund may not sum to 100 because cash, receivables and payables are reported on separate lines or not at all. Derivative line items, swaps and futures in particular, carry notional exposure rather than market value, so summing market value understates the fund's economic position. Some securities, especially non-US listings and private placements, will not map to any identifier in your security master. And the holdings count in the fund master is the only thing that tells you whether a short file is a concentrated fund or a truncated download.
Coverage breadth determines whether the join leaves holes. AmericanETP covers 3878 US and global indexes and US-traded ETFs, which means the join is against a single source rather than against a patchwork where some funds resolve and others return nothing.
The choice between pulling this through an API and taking scheduled files is a genuine architectural decision rather than a preference, and it is unpacked in ETF holdings data: API versus CSV delivery.
How do you read a thematic ETF's full holdings file and weightings?
Start with the as-of date, not the first row. A holdings file without a date in it or in its filename cannot be reconciled against anything, and for thematic funds in particular the composition on the date you need and the composition today can differ materially.
Then separate the three quantity columns, because they answer different questions. Shares held is a position count and changes only when the fund trades or the share count changes. Market value is shares multiplied by price and moves every day with no trading at all. Weight is market value divided by net assets, so it moves when the position moves and when every other position moves.
Weights frequently do not sum to exactly 100, and that is usually correct rather than an error. Cash, collateral, accrued income and unsettled trades can appear as separate lines, be netted into net assets without a line of their own, or be excluded from the holdings disclosure entirely. A file summing to 99.6 is normal; a file summing to 87 needs an explanation before you use it.
Leveraged and inverse funds will not reconcile on market value at all, because the exposure sits in swaps and futures whose market value is the mark on the contract rather than the notional it controls. Read the leverage factor and inverse flag from the fundamentals data and treat the holdings file as a description of how the exposure is obtained, not of how large it is.
Finally, sanity-check the fund against its stated mandate. Group the holdings by sector and compare against what the fund says it does: a clean-energy fund where industrials and utilities dominate is probably behaving as designed, while one where financials lead is worth a second look. The classification side of that check is covered in the ETF list by sector classification guide.
Ticker symbols, exchange codes and Bloomberg identifiers
A bare ticker is not a primary key. The same symbol can be in use on more than one venue and, across time, the same symbol can refer to more than one instrument, which means any join keyed on ticker alone will eventually match the wrong row and give you no error when it does.
Two things fix it. An exchange code qualifies the ticker to a venue, turning a potentially ambiguous symbol into a unique one at a point in time. A FIGI goes further by remaining stable across the events that change a ticker, which is what makes a historical join reproducible rather than merely currently correct.
The composite versus venue-level distinction matters when you load a CSV into a security master. A composite-level identifier represents the instrument across a country's venues and is the right grain for most portfolio and research work. A venue-level identifier represents the instrument on one specific exchange and is the right grain for execution and for any analysis where venue matters. Mixing the two in one column is a defect that surfaces months later as duplicate positions.
Building a Bloomberg ticker list from an ETF CSV
If the destination is a Bloomberg workflow, the fields you need from the CSV are the local ticker and an exchange qualifier, assembled into the ticker-plus-exchange-plus-yellow-key form the terminal expects. Doing this from a file that carries FIGIs is materially more reliable than doing it from names, because the FIGI resolves ambiguity before string matching gets a chance to introduce it.
AmericanETP includes Bloomberg FIGIs in the holdings files, so that column is the one to build the mapping layer from rather than reconstructing identity from fund names.
Validating a downloaded ETF CSV before anything reads it
Treat every delivery as untrusted until it passes a fixed sequence of checks, and fail the load rather than warn, because a partially correct file loaded silently is worse than no file. Seven checks catch the overwhelming majority of real problems.
- Row count against the previous delivery. Flag any change beyond a tolerance you set deliberately, perhaps one or two percent for a fund master.
- Duplicate identifier test. Group by the key you actually join on, ticker plus exchange code, or FIGI. Any group larger than one is a defect.
- Null rate per column. Track it per column over time. A column that is normally two percent null and is suddenly forty percent null signals an upstream change, not a market event.
- As-of date freshness. Assert that the date in the file matches the date you expected. This is the check that catches a stale file served from a cache.
- Leverage and inverse flags reconciled against fund names. A name containing "2X" or "Ultra" against a leverage factor of 1 is a mismatch worth investigating in either direction.
- Weight sums per fund. For holdings files, assert each fund's weights sum within a band, and review anything outside it rather than normalising it away.
- Column-level diff against the prior day. Compare the header, not just the data. Silent schema changes are the failure mode that breaks production at 6:05pm.
A worked example
A four-person quant team at a Chicago RIA automates these checks against the evening delivery. Monday's fund master had 3,104 rows. Tuesday's has 3,061, a drop of 43, which clears the row-count alarm set at one percent.
The diff shows 47 tickers removed and 4 added. Three of the removals carry a listing status of closed in the prior file, which is a real market event. The other 44 share a characteristic: every fund name contains a comma, and the parser consumed the delimiter because the quoting convention changed upstream.
Without check seven the file would have loaded, 44 funds would have disappeared from the universe, and the first symptom would have been a rebalance that skipped positions nobody noticed were gone. The checks cost an afternoon to write, and the right time to write them is against a historical file you already hold rather than against the first live delivery. The failure they caught would have cost considerably more.
Licensing, redistribution and what the free files do not grant
Being able to view a table in a browser is not the same as being licensed to redistribute its contents, and the gap between the two is where commercial users get into trouble. Most aggregator terms of use permit personal viewing and prohibit systematic extraction and onward distribution, which covers both the scraper and the product you built on top of it.
Index names and index membership data carry their own licensing layer, separate from the ETF reference data. Identifier schemes differ too: FIGIs are openly licensed, while some national identifier schemes are not, which is why a given file may carry one and not the other. If your product displays or redistributes any of it to clients, the licence question arrives before the engineering question.
AmericanETP publishes its pricing directly: $1500 per year or $150 per month for an individual, and $2500 per year or $250 per month firm-wide, with FTP access available for scheduled retrieval. The business was founded in the 1990s as MasterDATA, predating most current ETF data competitors, and was renamed to AmericanETP to avoid confusion with IBM's use of the MasterDATA term.
Licensed inputs matter most for anything you publish downstream. Aggregate valuation work of the kind described in how the S&P 500 PE ratio is computed and in trailing, forward and weighted S&P P/E depends on membership and weighting data whose provenance you can state, because the output is only as defensible as the universe behind it. If you need to confirm what a particular licence covers for your use case, ask the provider directly rather than inferring it from a summary of their terms.
FAQ
Can you provide a list of all ETFs?
Yes, with a caveat about scope. A complete list of US-traded ETFs, delivered as CSV with identifiers and attributes, is a standard commercial product; AmericanETP's coverage spans 3878 US and global indexes and US-traded ETFs. A list of all ETFs globally is a harder problem because it crosses dozens of regulatory regimes, listing venues and identifier schemes, so always check which universe a given file actually covers before treating "all" literally.
How many ETFs are there in 2026?
The honest answer is that the count depends on the definition and the date, and any single figure quoted without both is unreliable. Decisions about whether to count exchange-traded notes, whether to count multiple listings of the same fund once or separately, and whether to include funds that closed earlier in the year can move the total substantially. The defensible approach is to count rows in a dated file from a source whose inclusion rules you can read, and to state the date alongside the number.
Is there a free CSV download of all ETF tickers?
Free ticker lists exist, from exchange listing directories, community repositories such as the ETFs.csv file on GitHub, and some aggregator sites. What they generally do not include is a reliable as-of date, a listing-status column, leverage and inverse flags, cross-venue identifiers, or a redistribution licence. They are adequate for exploratory work and inadequate as a production dependency.
How often should an ETF list CSV be updated?
Daily is the practical floor for anything that trades or reports, because launches, closures, ticker changes and venue moves occur on any business day. Holdings data changes faster than fund reference data and should be refreshed on every available cycle. AmericanETP updates twice daily, with a primary run at 6pm EST and a secondary run around noon EST.
Do ETF CSV files include delisted or closed funds?
Current-state files usually do not, and that omission is the mechanism behind survivorship bias in any analysis built on them. Including closed funds requires either a listing-status column that retains historical rows or an archive of point-in-time files. AmericanETP's archived holdings datafiles go back to July 2009, which is what allows a universe to be reconstructed as it existed on a past date rather than as it exists now.
What is the difference between an ETF list and an ETF holdings file?
An ETF list has one row per fund and describes the funds themselves: identifiers, issuer, asset class, leverage, listing status. A holdings file has one row per position per fund and describes what each fund owns, with weights, share counts and market values. The list answers what exists; the holdings file answers what is actually held, and it is the substantially harder and more expensive of the two to source and maintain.
If you need ETF and index holdings as clean CSV files with FIGIs included, twice-daily updates and an archive going back to July 2009, see what AmericanETP delivers.