U.S. Non-Profit Organizations Database Updated: 1,960,014 Records

The U.S. Non-Profit Organizations Database has a new release. Build #161, version 2.0.0, brings together 1,960,014 selected U.S. tax-exempt organization records in a structure that can be used for research, directories, analysis, and application development. Each organization has one base row identified by its EIN. Depending on the package, that row connects to a tax profile and a financial snapshot without forcing every field into one oversized table.

What this release contains

The October 8, 2026 release covers organizations with filing or headquarters addresses in all 50 states and the District of Columbia. The address in a record identifies where the organization files or is headquartered. It should not be counted as every physical site where the organization works. One organization may operate in several places; another may use a mailing address that is separate from its programs. This distinction matters when a map, report, or search result seems to turn an address into an operating-location claim.

The collection is one record per distinct EIN in the selected release population. Its scope includes multiple tax-exempt categories, not only charitable organizations. That breadth makes it useful for questions beyond donation research, but it also calls for precise labels. A page that describes all 1,960,014 rows as charities would misstate the collection. A better starting point is to describe them as selected tax-exempt organization records and use the published classification fields for narrower questions.

The release has three connected tables: organizations, tax_profile, and financial_snapshot. Each table contains 1,960,014 rows in this build, keyed by EIN. A row count shared by the tables does not mean every tax or financial field is populated. The snapshot records the available source fields and their relevant periods. Treat missing values as missing data, not zeros or proof that an organization had no activity.

A package ladder built around the same key

Usage: Organization Directory

Usage provides the organizations table. It includes names, EINs, filing addresses, and basic classification fields in the released schema. This is the leanest way to explore the selected population, build a searchable internal reference, compare filing areas, or match an existing list against an EIN. The base table gives an application a stable organization object rather than asking it to infer identity from a name or address, either of which can change or be shared.

For example, an analyst can filter by filing state and inspect classifications before selecting a smaller set for manual review. A directory application can begin with name and EIN lookup, then decide how much context to show on a record page. If the project later needs tax-profile fields, the EIN already provides the join. The Usage package is a useful starting point for internal work; it does not contain the two additional tables included in the higher packages.

Publication: Organization and Tax Profile

Publication adds tax_profile to the organization directory. The profile carries published exemption, affiliation, and filing codes where available. It is intended for work that needs to describe the selected organizations with more context, such as a research report, a customer-facing lookup, or a filtered application. Keep the code definitions and source context alongside any simplified labels in the interface so a reader can tell what was recorded and what the application inferred.

One useful pattern is to keep the organization row as the primary result and join the tax profile only for the fields a particular view needs. A category filter can use the profile without copying every code into every search result. A detail page can show a short summary and link to a fuller field explanation. This makes the relationship easier to maintain when the data is refreshed and avoids treating a classification as a complete account of an organization's current work.

Master: Complete Organization Reference

Master includes the lower-tier tables and adds financial_snapshot. This table contains return-derived financial fields and their tax periods where those values are available in the source snapshot. It supports projects that compare reported figures, inspect a specific filing period, or add financial context to a record. A financial value without its period can be misleading, especially if two organizations have different reporting schedules or if one record lacks a value.

The financial table should be joined to the same EIN, then displayed with its field name, tax period, and any missing-value treatment. A project comparing organizations should first decide whether it is comparing the same measure and compatible periods. A dashboard should not silently make a blank field look like zero. The Master package offers the richest released reference, but the application still needs judgment about what each source value can support.

How the joins work in practice

Start with organizations.ein and join the corresponding ein in tax_profile or financial_snapshot. Keep the EIN as an identifier, including any leading zeros, rather than treating it as a number for arithmetic. Preserve the original field definitions when importing CSV or JSON into another system. SQLite provides a ready relational starting point for exploring the same structure without building a separate database server first.

As a simple example, an organization detail page can show the name and filing address from organizations, selected exemption and filing codes from tax_profile, and a clearly dated financial field from financial_snapshot. The reader sees one organization, while the application keeps the source layers separate. A research export can choose only the columns it needs and still retain the EIN needed to trace the joined values back to their released tables.

The same structure also helps when a project does not need all three tables. A map of filing areas can use the base directory without importing financial fields. A classification analysis can add the tax profile. A financial study can add the snapshot after it has checked period coverage and blanks. This tiered design makes the extra detail explicit rather than hiding it in a single large download with unclear field provenance.

Each package includes CSV, JSON, and SQLite deliverables, along with the accompanying schemas, samples, statistics, and documentation. CSV is convenient for a spreadsheet or tabular import. JSON fits many application pipelines. SQLite is useful for joining and querying the tables directly. Before choosing a package for a production project, inspect the public sample and the released field schema, then try the intended query against a representative subset.

What the data does and does not establish

This is a dated public-data snapshot, not a live certification of every organization's current tax status, donation eligibility, address, or financial condition. Exemption status, contribution deductibility, and reported figures can change after the snapshot. Some categories and financial fields are unavailable for some records. If a decision depends on a current legal or tax position, check the applicable current authoritative record rather than using a downloaded field as the sole answer.

The dataset is not an exhaustive list of every nonprofit, church, or self-declared organization. It selects records from the sources used for this release and records the resulting population. A count of 1,960,014 tells you how many distinct EINs are in this package, not how many nonprofits exist in the United States. Likewise, the 51 represented state and DC filing areas describe the address field in the selected rows; they do not count service areas or branch sites.

When building a public interface, make those limits visible where a reader may draw a stronger conclusion. Label a map as filing or headquarters geography. Name a code for what the source records, not for an unsupported real-world claim. Put the period near a financial value. Allow room for a correction or a later source check. These practices help users interpret the release accurately without making the interface feel like a legal disclaimer.

For outreach or prospecting uses, the presence of an organization in a data file is not evidence of marketing consent. A project that intends to contact people or organizations needs its own current contact, privacy, permission, and suppression processes. The database can support research and matching, but it does not replace those operational checks.

Choose the detail your project needs

If you need a national organization reference or an EIN-based lookup, begin with the Organization Directory. If you need to publish richer classification or filing context, compare the Publication package. If you need return-derived financial context with the relevant periods, review Master. The packages share the same base identity so the choice is about the fields and permitted use required by the work.

Review the product page for current package details, sample files, and the applicable license before purchase. The page shows which tables are included in each tier and the current release version. If your project needs a narrower topic, unusual geography, or fields absent from the published sample, Oddity can help assess whether this package fits or whether a custom data scope would be more useful.

This announcement describes the October 8, 2026 release. The package reflects its documented source snapshot. Specific records and real-world conditions may change after that date.