For a long time, municipal ordinance lived in a PDF. Sometimes the PDF was a scanned image of a 1978 typewriter draft that had been re-adopted, line by line, through thirty years of amendments. Reading it was a manual skill, and building software against it was a project that never quite finished.
That is changing, unevenly, and faster than most of the industry realizes.
What structured ordinance data means
A structured code is one where the hierarchy of the law is expressed in machine-readable form. Title, chapter, article, section, subsection, paragraph. Each node has an identifier, a parent, a heading, and a body. Cross-references resolve. Amendments are tracked with effective dates. A search for "front yard setback" returns the specific section with its position in the hierarchy, not a page number in a PDF.
Two companies dominate the US market. Municode, owned by Civic Plus, and American Legal Publishing, usually shortened to AmLegal. Between them they host the code for a majority of US cities with populations above 10,000. Both have published APIs. Both are imperfect. Neither is comprehensive.
Where coverage is good
Large and mid-sized cities are generally on one of the two platforms. Chicago, Denver, Austin, Phoenix, Atlanta, and most of the metro areas in California and Florida publish current code through Municode or AmLegal. A query against either platform's API returns a JSON tree you can walk.
Where it works, the developer experience is surprisingly clean. You get a hierarchy, you get section bodies, you get a cross-reference resolver. The API rate limits are lenient enough for production use if you cache reasonably.
Where coverage breaks down
The gap is in smaller jurisdictions, counties, and special districts. Counties in particular are the problem. A county unified development ordinance is often hosted on the county's own website as a PDF, sometimes with OCR errors, sometimes with a search that indexes headings but not body text. A majority of US counties are in this state.
Special districts are worse. Airport authorities, port districts, historic commissions, improvement districts. These bodies adopt their own regulations, publish them in whatever format the district attorney prefers, and rarely appear on Municode or AmLegal.
Home-rule cities sometimes host their own code. Portland, Oregon has its own platform. Seattle has its own. New York City's Zoning Resolution lives on a dedicated city portal.
The upshot: if you are writing software that needs to reach a lot of jurisdictions, you will touch three tiers. The first tier is Municode and AmLegal, cleanly accessed through APIs. The second tier is city-specific or county-specific structured sites, each requiring a custom integration. The third tier is PDFs, and the PDFs require parsing.
What we do about the PDFs
For PDFs, the pipeline is layout detection, then OCR, then heading extraction, then chunking. Document layout models have improved enough that a clean civil ordinance PDF can be parsed into a near-Municode-quality tree. A scanned PDF with embedded tables is still a research problem. We process both, but we flag the confidence level on the second case and route it differently during retrieval.
The interesting observation is that for the purposes of retrieval, near-Municode-quality is often enough. A retrieval system does not need perfect hierarchy reconstruction. It needs to find the right paragraph and cite it. The citation can be a page-plus-heading reference rather than a full section path.
Where this goes in 2026
Three trends are clear.
First, coverage is expanding on Municode and AmLegal. More counties are signing up. The long tail is still long, but the short head is getting shorter.
Second, state legislatures are pushing toward uniform publication standards. California's local code modernization work is the most advanced. Several other states are looking at it.
Third, AI-driven ordinance parsing is making the third tier, the raw PDFs, work well enough for production use. The quality gap between "on Municode" and "scraped from a county PDF" is narrower than it was two years ago.
What developers should know
If you are building a product that reads municipal code, start with the Municode and AmLegal APIs. Cover what you can with structured access. Write a careful PDF pipeline for the rest. Label your sources. A user needs to know whether the answer came from a clean API pull or a scraped document, because the failure modes are different.
Do not promise coverage of every jurisdiction. No one has it. Everyone is working on it.