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 what your GIS actually reads to know what the coordinates mean — lose it and the numbers are unlabelled..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). We will not ask you for a .prj — a bare .dbf carries no geometry, so there is no projection to name for the file itself. But if your attribute table holds latitude and longitude columns we will read them, and nothing in a lone .dbf says which datum they are in — so we tell you that rather than assume WGS 84. If you also have the .shp, upload the whole zipped bundle instead and we read the geometry and CRS too. Free during the testing period · no account needed · without one, what we read is kept to teach the reader, names removed; sign in and nothing is kept.