Shapefile · dBASE
What you are seeing — you have a folder of files with the same name and different extensions, and the one holding your actual data will not open in anything you have.
A .dbf is the attribute table of a shapefile — the rows and columns, with no geometry. It is a dBASE file, a format older than the web, and you do not need ArcGIS to read it.
Three free options, in the order most people should try them: LibreOffice Calc opens a .dbf directly (File → Open, pick the file) and will save it straight back out as CSV. QGIS opens the whole shapefile — drag the .shp in, right-click the layer, Open Attribute Table, then Export → Save Features As → CSV. ogr2ogr, part of GDAL, does it in one line if you already have it installed.
Two things will look wrong and are not bugs. Your column names are truncated to 10 characters — the .dbf field descriptor allots 11 bytes for a name, and ESRI's software caps what it writes there at 10, so coordinateUncertaintyInMeters became coordinate the moment somebody saved it as a shapefile, and the original name is gone. Accented characters may be mangled — a .dbf carries no reliable declaration of its own character set. If there is a .cpg file beside it, that file names the encoding; if there is not, you are guessing, and the usual answer is that it was written on Windows in a single-byte code page.
.shp, .shx, .dbf, and .prj if it exists. Opening the .dbf alone loses the coordinates and the .prj is the only record of what those coordinates mean..shp in QGIS rather than the .dbf in a spreadsheet, if you have the choice — that way the coordinates come with it..prj before you trust the numbers, and note that it fails in two very different ways. If it names a projected system — a UTM zone, a state plane, a national grid — your coordinates are metres, not degrees, and they are obviously wrong the moment you look at them. If it names a different geographic datum (NAD27, ED50), they are still latitude and longitude and still look completely normal, but they sit tens to hundreds of metres from where WGS 84 would put them. The second one is the dangerous case, because nothing about it looks like an error.Upload the .dbf alone — no .shp, no zip — and we read every attribute column, plus exactly what the shapefile format already did to your column names before you ever got here (the 10-character cut, any collisions, and which of those are unrecoverable without a second source). There is no coordinate system question to answer here, because a bare .dbf has no geometry column — that half of the format is just the table, and reading it is not a guess. Free, permanently. If you also have the .shp, upload the whole zipped bundle instead and we read the geometry and CRS too. Free until 1 September, no account, and your records are discarded after the check —
we keep the column mapping, never the rows.
We audited a file GBIF had already accepted and served. Their validator answers will this load; these had loaded. Figures read from ops/data.json, not typed into this page. We do not issue a rating of any kind — every finding names the rule it applied and where that rule comes from.