ExcelDataReader: thirty years of Excel formats through one IDataReader

BIFF2 to OpenXml, one reader for thirty years

The supported format table reads like an archaeology of Excel. On the modern side, .xlsx files from 2007 onward arrive as ZIP or CFB plus ZIP containers in OpenXml, with .xlsb, the binary OpenXml variant, in a ZIP or CFB container from the same era. The .xls extension alone covers five BIFF generations, BIFF8 from Excel 97, 2000, XP and 2003 plus the Mac releases 98, 2001, v.X and 2004, BIFF5 for 5.0 and 95, and BIFF4, BIFF3 and BIFF2 for versions 4.0, 3.0, and 2.0 through 2.2. Beyond binary there is SpreadsheetML, the 2002 and 2003 XML Spreadsheet format under the .xml extension, and CSV for all versions. The library's tagline, lightweight and fast, is credible precisely because reading this range is a parsing problem rather than an application emulation problem.

Two packages since 3.0: the reader and the DataSet helper

As of version 3.0 the project ships as two NuGet packages. The ExcelDataReader base package provides the low level reader interface, and the ExcelDataReader.DataSet extension package adds the AsDataSet() method that populates a System.Data.DataSet, pulling in the base package automatically. Both target net462, netstandard2.0 and netstandard2.1, covering .NET Framework and modern .NET without a compiled dependency split per runtime. The recommendation is to install through the Visual Studio Package Manager Console or the Manage NuGet Packages extension, and the choice between packages is really a choice of ergonomics, AsDataSet() for a quick dump into tables, the raw reader interface for streaming through large workbooks without materializing everything.

One factory call, format auto-detected

Usage begins with a stream and one factory method:

using (var stream = File.Open(filePath, FileMode.Open, FileAccess.Read))
{
    // Auto-detect format, supports:
    //  - Binary Excel files (2.0-2003 format; *.xls)
    //  - Legacy Excel XML Spreadsheet files (2002-2003 format; *.xml)
    //  - OpenXml Excel files (2007 format; *.xlsx, *.xlsb)
    using (var reader = ExcelReaderFactory.CreateReader(stream))
    {
        // Choose one of either 1 or 2:

        // 1. Use the reader methods
        do
        {
            while (reader.Read())
            {
                // reader.GetDouble(0);
            }
        }

CreateReader detects the container and format from the stream itself, spanning binary .xls, legacy XML Spreadsheet and OpenXml, so calling code does not branch on file extension. For plain text with comma separated values, ExcelReaderFactory.CreateCsvReader replaces CreateReader, with its own configuration surface for encoding and separator handling.

CSV parsed twice by design

The CSV reader has an unusual and documented two pass behavior. The input is always parsed once completely to set FieldCount, RowCount, Encoding and Separator, or twice if the file lacks a BOM and is not UTF8, and then parsed once again while the caller iterates the row records. If the bytes cannot be parsed with the specified encoding, the reader throws System.Text.DecoderFallbackException. For large files where RowCount is not needed upfront and FieldCount from the first row, a header row, is sufficient, setting AnalyzeInitialCsvRows = 1 limits the pre-scan to a single row and avoids reading the entire file twice. Two configuration options tune the behavior, FallbackEncoding for encoding detection and AutodetectSeparators for delimiter detection. And a ground rule shapes all CSV use, every field value comes back as a string, with no attempts to convert to numbers or dates, leaving interpretation entirely to the caller.

IDataReader and IDataRecord over your workbook

The central design decision is the interface inheritance, IExcelDataReader extends System.Data.IDataReader and IDataRecord, the interfaces ADO.NET code has consumed from databases since the beginning. That choice defines the whole method surface. Read() reads a row from the current sheet, NextResult() advances the cursor to the next sheet, mapping sheets onto result sets, and ResultsCount returns the number of sheets in the workbook. Name returns the current sheet's name, and CodeName returns its VBA code name identifier, a detail only a library that reads real workbooks would surface. FieldCount returns the column count of the current sheet. The result is that code written against a data reader transfers almost directly to reading spreadsheets, with sheets where tables would be and rows where records would be.

RowCount counts what AsDataSet drops

The subtle differences between the two consumption styles are documented rather than discovered. RowCount returns the number of rows in the current sheet including terminal empty rows, which are otherwise excluded by AsDataSet(), so the raw count and the DataSet count can legitimately disagree on a workbook with trailing blanks. On CSV files, RowCount throws InvalidOperationException when used together with AnalyzeInitialCsvRows, because the pre-scan that would compute it was deliberately skipped. Depth always returns 0, stated plainly because ExcelDataReader does not expose nested result sets, an honest refusal to pretend shape handles exist. AsDataSet() itself is described as a convenient helper for quickly getting the data, but not always available or desirable, which is the README nudging large or streaming workloads toward the reader methods.

PRs go to develop, issues bring files

The contribution norms are short and practical. Pull requests should target the develop branch, which is also the repository's default, and issue reports carry one unusual request stated with unusual force, it is really useful if you can supply an example Excel file, as this makes debugging much easier, and without it we may not be able to resolve any problems. For a parsing library that claim is close to literal, most defects are reproducible only against the specific malformed or unusual workbook that triggered them, so the example file is the bug report. A GitHub Actions continuous integration workflow runs on the repository, and StyleCop and EditorConfig configuration files at the root enforce the code style contributions must match.

An slnx solution and a 3.9.0 release

The repository itself shows a project keeping its toolchain current, with the solution file in the newer XML-based .slnx format rather than classic .sln, a Directory.Build.props centralizing build settings, and .globalconfig and stylecop.json governing analysis. Release v3.9.0 shipped 2026-06-16, preceded by an rc1 on 2026-06-04 and numbered develop builds through May 2026, and the repository's last push landed 2026-09-27, days before this writing. The license is MIT, the language is C#, and the package lives on NuGet under the ExcelDataReader name with its DataSet extension beside it, a small dependency footprint for a library whose job is unpacking three decades of other people's file formats.

Editorial conclusion

Use ExcelDataReader when .NET code must ingest spreadsheets read only, especially mixed archives of old binary .xls files alongside modern .xlsx, since its format coverage runs deeper into history than most alternatives and its IDataReader surface plugs into familiar ADO.NET idioms. Use a full spreadsheet library instead when documents must be written or styled, this project only reads. Before adopting, pick the right package, the base reader or the DataSet extension for AsDataSet, remember CSV values arrive as strings with no numeric or date conversion, and when reporting an issue attach an example workbook, since the maintainers state plainly that without one they may not be able to resolve problems.

Frequently asked questions

Official sources

1. ExcelDataReader/ExcelDataReader on GitHub
2. Issues
3. License: MIT
4. README
5. Releases