Data Access: Make a Public Spreadsheet Usable

Suppose you have monthly library-visit totals in a spreadsheet. A journalist needs to check one branch; a researcher needs the whole table; a developer wants to retrieve selected records. Sending the same spreadsheet attachment to everyone is not the only option.

Data access means being able to retrieve or work with data. For a public dataset, the practical task is to provide the right access method—and enough context to use the numbers correctly.

The target result: a reviewed public table readers can explore, a machine-readable copy they can reuse, and documentation that explains what each row means.

Choose access methods by reader task

Reader task	Useful access method	What to provide
Look up a branch or compare months	Interactive web table	Clear headings and useful filters
Recalculate totals or join another dataset	Downloadable file	A complete, reviewed CSV or workbook with definitions
Retrieve selected records repeatedly	API	Documentation covering fields, filters, pagination and errors

An API, or application programming interface, lets software request data without manually browsing the page. You do not need one just to publish a small, occasional release.

A browser view and a downloadable file serve different purposes. W3C’s Data on the Web Best Practices recommends both bulk retrieval of a complete dataset and useful subsets for large datasets. A filtered view should not leave readers guessing how to obtain the full release.

Prepare a public release, not your working file

Start by confirming that you have permission to publish and redistribute the data. Public visibility is not the same as permission to reuse it: W3C recommends providing a link to, or copy of, the license governing use.

Keep private source records separate. Do not upload sensitive information to a public publishing service. Review the entire release file, including extra sheets and notes, rather than assuming the visible worksheet is the whole upload.

For the library example, publish branch-level monthly totals—not patron records. Here is an invented sample dataset, not a real library release:

branch_id	branch_name	month	visits
B01	Central	2026-01	120
B01	Central	2026-02	135
B02	Riverside	2026-01	90
B02	Riverside	2026-02

Define one row as one branch in one calendar month. Check that each branch_id–month pair occurs only once. Keep visits numeric; do not put explanatory text in that column.

The blank is deliberate: it means “not reported,” not zero. The sum of reported values is 345, but that is not a complete two-branch, two-month total.

For a fuller preparation checklist, use Clean Data Sheets. If you choose CSV, check what CSV conversion preserves and loses before exporting.

Put definitions beside the access link

A file can open successfully and still be unusable. Attach a short dataset note to the public page or its accompanying documentation:

• Coverage: which branches and months are included, and which are excluded.
• Definitions: what counts as a visit, including whether repeat visits count separately.
• Missing values: what blanks mean and whether any values are withheld.
• Source and processing: the original source, plus any aggregation, exclusions or corrections you made.
• Release details: publication date, version identifier, expected update schedule and changes since the previous release.
• Reuse terms and contact: the applicable license and where to report an error.

This is metadata: information describing the dataset. W3C recommends documenting both the overall dataset and its internal structure, as well as its origins and changes.

Publish the reviewed table

As of October 29, 2026, TablePage’s homepage lists CSV, TSV, XLSX and XLS uploads, public dataset pages, and a filterable table readers can explore without signing up. It also lists a public API for programmatic dataset access.

Upload only the reviewed release copy. Keep the definitions alongside the shared page, whether on that page or in a clearly linked companion document. If readers need a complete downloadable file, provide and test that access route separately; do not assume an interactive table includes it.

Test access as a reader

Before sharing the link, open it in a signed-out browser and check:

1. Entry: can the intended public reader reach the table without requesting permission?
2. Completeness: do the unfiltered row count and columns match the release file?
3. Interpretation: are units, coverage, missing-value rules and source information easy to find?
4. Retrieval: does the download contain the complete release, or a clearly labeled subset?
5. Software access, if offered: can an API consumer retrieve all intended records across pages without omissions or duplicates?

For the invented sample, the unfiltered view should contain four rows. Filtering to Central should show two rows whose visits sum to 255; Riverside’s February value should remain missing. Those checks verify useful data access—not merely that a link opens.