Convert CSV Coordinates to GeoJSON Without Swapping Latitude and Longitude

Converting a table of locations into GeoJSON looks straightforward: choose the latitude and longitude columns, then create one point for each row. The conversion itself is easy. Trusting the result without checking it is where trouble starts.

The most common failure is a coordinate-order mistake. Spreadsheets usually describe a location as latitude followed by longitude. GeoJSON stores a position in the opposite order: longitude first, latitude second.

This guide shows the conversion with a small example, explains what happens to the other columns, and gives you a short set of checks to run before opening the file in a map.

What the source CSV should contain

For point data, you need one row per location and two coordinate columns in decimal degrees. The column names do not have to be latitude and longitude, but clear names make mistakes less likely.

facility_id,name,latitude,longitude,status
BOR-001,Muna Clinic,11.8846,13.1571,active
BOR-002,Custom House Clinic,11.8334,13.1507,active
BOR-003,Old Town Store,not recorded,13.1490,closed

The first two rows have usable coordinates. The third does not: not recorded is not a number, so it cannot become a point.

Before converting, check that:

• latitude and longitude are in separate columns;
• the values use decimal points rather than degree symbols or compass letters;
• latitude is between -90 and 90;
• longitude is between -180 and 180; and
• missing coordinates are blank rather than represented by a plausible number such as 0.

Zero is a valid coordinate. Replacing missing values with 0,0 creates apparently valid points in the Gulf of Guinea and hides the data-quality problem.

Convert the file in HappyCSV

Open the CSV to GeoJSON converter and select the CSV file. HappyCSV tries familiar headings such as latitude, lat, longitude, lon, and lng. Confirm the selections instead of relying on detection when the headings are ambiguous.

The file is processed in your browser. Each valid row becomes a GeoJSON Feature with a Point geometry. The remaining columns are retained as properties.

The first row above becomes:

{
  "type": "Feature",
  "geometry": {
    "type": "Point",
    "coordinates": [13.1571, 11.8846]
  },
  "properties": {
    "facility_id": "BOR-001",
    "name": "Muna Clinic",
    "status": "active"
  }
}

Notice the coordinate array: [13.1571, 11.8846], or [longitude, latitude].

That order is required by the GeoJSON standard, RFC 7946. It is not a HappyCSV convention. Reversing it may place the feature thousands of kilometres away or produce an invalid latitude.

Why the other columns become properties

GeoJSON separates location from descriptive data. The geometry says where the feature is. The properties say what it represents.

Keeping facility_id, name, and status as properties means a GIS application can label, filter, style, or join the points without changing their coordinates. It also means headings deserve the same care as coordinates. Duplicate or blank CSV headers lead to unclear property names.

Identifiers should usually remain text. A code such as 00127 is not a quantity; converting it to a number removes the leading zeros and may break a later join.

Check the output before relying on it

Do not judge a location file only by whether it opens. Run these checks:

1. Compare the feature count with the CSV row count. If the numbers differ, identify which rows were skipped and why.
2. Inspect one known location. Confirm that its coordinates and properties match the source row.
3. Check the geographic extent. A dataset of facilities in one Nigerian state should not include points in Europe or the Atlantic.
4. Look for clusters at 0,0. They usually indicate missing coordinates that were encoded as zero.
5. Open the file in the destination application. A valid GeoJSON file can still be unsuitable for the next step because of field names, data types, or an unexpected geometry requirement.

For a quick visual check, drag the output into a GIS application such as QGIS or a trusted GeoJSON viewer. If the data is sensitive, prefer a desktop application or confirm that an online viewer does not retain uploads.

Common problems

The points appear in the wrong country

Latitude and longitude were probably swapped. Inspect one coordinate array. GeoJSON should contain longitude first.

Some rows disappear

Look for blank coordinates, text mixed into numeric columns, commas used as decimal separators, or values outside the valid ranges. Fix the source data and convert it again rather than inventing coordinates.

The map is close, but consistently offset

The source coordinates may use a projected coordinate reference system rather than WGS 84 longitude and latitude. Values such as 532418 and 1315567 are not decimal-degree coordinates. They need a coordinate transformation in GIS software before conversion.

RFC 7946 defines GeoJSON coordinates using WGS 84 longitude and latitude in decimal degrees. Simply renaming easting and northing columns will not transform them.

A place name is available, but coordinates are not

That requires geocoding, which is a separate process. A CSV-to-GeoJSON converter does not determine coordinates from addresses or place names.

Converting the file back to CSV

Use GeoJSON to CSV when you need to inspect or edit point properties in a spreadsheet. Point coordinates can be restored as longitude and latitude columns. Complex geometries such as polygons and lines do not fit neatly into ordinary columns, so decide whether you need their full geometry or only their attributes before converting.

The useful rule is simple: treat conversion as a change of representation, not as proof that the underlying location data is correct.