How to Convert GeoJSON to JSON (Strip Geometry, Keep Properties)
What GeoJSON Actually Contains (and Why It's More Than You Need)
GeoJSON is a geospatial data format built on top of regular JSON. Every GeoJSON file wraps your data inside a predictable structure: a top-level FeatureCollection object that holds an array of Feature objects, and each Feature carries two main keys — geometry and properties. The geometry block stores coordinate arrays, shape types (Point, LineString, Polygon, MultiPolygon, etc.), and sometimes nested coordinate rings that can run thousands of lines deep. The properties block is where your actual attribute data lives: names, IDs, population counts, category labels, timestamps — whatever metadata was attached to each geographic feature. The problem arises when you need to pass that data to a system that has no use for coordinates. Imagine you've exported a dataset of 4,200 U.S. county boundaries from a GIS tool. The resulting GeoJSON file might be 18 MB because each county polygon contains hundreds or thousands of coordinate pairs. But if you only need the county name, FIPS code, and population figure for a data pipeline, a reporting dashboard, or a REST API payload, you're shipping roughly 95% unnecessary data. The geometry is dead weight, and some downstream parsers will reject the file outright because they don't expect geospatial keys. Stripping geometry and extracting just the properties array is a completely legitimate data-transformation task — it's not lossy in any meaningful sense for non-spatial use cases.
The Structure Difference: GeoJSON vs. Plain JSON
Before converting anything, it helps to see exactly what you're working with. A minimal GeoJSON Feature looks like this: { "type": "Feature", "geometry": { "type": "Point", "coordinates": [-87.6298, 41.8781] }, "properties": { "city": "Chicago", "population": 2696555, "timezone": "America/Chicago" } } After conversion — stripping geometry and keeping properties — the target plain JSON output for that same feature should be: { "city": "Chicago", "population": 2696555, "timezone": "America/Chicago" } For a FeatureCollection with multiple features, the expected output is an array of those flattened property objects: [ { "city": "Chicago", "population": 2696555, "timezone": "America/Chicago" }, { "city": "Houston", "population": 2304580, "timezone": "America/Chicago" } ] This is what most APIs, spreadsheet imports, and database loaders actually want. Notice that the type, geometry, and FeatureCollection wrapper are all gone. The result is a clean, flat JSON array — interoperable with virtually any tool that speaks JSON. One thing to be aware of: if any of your features have a null properties value (which is valid GeoJSON), the conversion should produce an empty object {} for that feature rather than crashing or skipping it. Good converters handle this gracefully; sloppy ones don't.
Converting GeoJSON to JSON with CocoConvert
CocoConvert's dedicated GeoJSON-to-JSON converter at /convert/geojson-to-json is built specifically for this extraction task. The workflow is straightforward: upload your .geojson or .json file (GeoJSON files sometimes carry a .json extension — both are accepted), choose your output options, and download the result. Here's what the conversion does by default: it reads the features array from your FeatureCollection, pulls the properties object from each Feature, and writes those property objects into a JSON array. The geometry key, the type key, and the FeatureCollection wrapper are all dropped. If your file is a single Feature rather than a FeatureCollection, the output will be a single JSON object rather than an array. A few practical notes on file size and performance: CocoConvert handles files up to 50 MB on the free tier. Most GeoJSON files with under 10,000 features fall well within that limit. If you're working with a state-level road network or a global administrative boundaries dataset that weighs in at 200 MB or more, you'll need to split the file first or use a command-line approach (covered in the next section). The converter processes files server-side and does not store your data after the session ends, which matters if your GeoJSON contains sensitive attribute data like addresses or personal identifiers. After conversion, the downloaded file will be named with a .json extension. If you need a specific filename or want the output formatted with indentation for readability rather than minified, those options are available in the settings panel before you trigger the download.
Command-Line Alternatives for Large Files or Automation
For files over 50 MB, or when you need to run this conversion repeatedly as part of a data pipeline, a command-line approach is more practical. Two tools are worth knowing: jq and Python's built-in json module. Using jq (the fastest option for pure JSON transformation): jq '[.features[].properties]' input.geojson > output.json That single line does exactly what CocoConvert does: it iterates over every feature, extracts the properties object, and writes the results as a JSON array. jq is available via Homebrew on macOS (brew install jq), apt on Debian/Ubuntu (apt install jq), and as a standalone binary on Windows. It handles files in the gigabyte range without breaking a sweat because it streams rather than loading everything into memory. If you need to add the feature ID to your output (which lives outside properties in GeoJSON), modify the command: jq '[.features[] | {id: .id} + .properties]' input.geojson > output.json Using Python when you need more control: import json with open('input.geojson') as f: gj = json.load(f) result = [feature['properties'] for feature in gj['features']] with open('output.json', 'w') as f: json.dump(result, f, indent=2) This is about 8 lines of code and gives you full flexibility to filter features, rename keys, or handle null properties before writing. Python's json module is part of the standard library — no installation needed. To be direct: CocoConvert is the right tool when you have a single file and want a result in under a minute without writing any code. jq or Python are better when you're processing dozens of files or integrating into a CI/CD workflow.
Handling Edge Cases That Break Naive Converters
Real-world GeoJSON files are messier than the spec examples suggest. Here are the specific edge cases that cause problems and how to handle them. Null geometry features: GeoJSON allows features with "geometry": null — these are valid and common in datasets where some records lack location data. A converter should still extract their properties rather than skipping them. If you're using jq, the command above handles this automatically. If you're writing Python, your list comprehension will work fine because null geometry doesn't affect the properties key. Nested properties: GeoJSON properties can themselves contain nested objects. For example, a feature might have "properties": {"address": {"street": "Main St", "zip": "60601"}}. The conversion preserves this nesting as-is — the geometry strip doesn't flatten nested property objects. If you need a fully flat structure for a CSV export or a SQL insert, that's a separate transformation step. Duplicate property keys across features: If some features have a "name" key and others don't, the resulting JSON array will have objects with inconsistent shapes. This is valid JSON but can cause issues in typed systems. CocoConvert doesn't normalize schemas — it faithfully extracts whatever is in each feature's properties block. You'd need to handle schema normalization separately. Large coordinate arrays in GeometryCollection types: If your GeoJSON uses GeometryCollection rather than standard Feature geometry, the structure differs from a FeatureCollection and some converters misread it. CocoConvert expects standard FeatureCollection input. If your file uses GeometryCollection at the top level, you may need to restructure it first. Encoding issues: GeoJSON is always UTF-8 by spec. If your file was exported from older GIS software and contains Latin-1 or Windows-1252 encoded characters in property strings, the converter will flag an encoding error. Fix this upstream with iconv or Python's codecs module before uploading.
When You Should Keep the Geometry (and Convert Differently)
Stripping geometry is the right move for attribute-only workflows, but there are cases where you actually want to keep the spatial data in a different format rather than discard it. If you're moving GeoJSON into a web mapping library like Leaflet or MapboxGL, you don't need to convert at all — both libraries consume GeoJSON natively. Converting to plain JSON and losing the geometry would break your map entirely. If you need the coordinates in a different structure — say, a flat array of {lat, lng, name} objects for a custom visualization — that's a reshaping operation, not a geometry strip. The jq approach handles this: jq '[.features[] | {lat: .geometry.coordinates[1], lng: .geometry.coordinates[0], name: .properties.name}]' input.geojson > output.json Note the coordinate order: GeoJSON stores coordinates as [longitude, latitude] (x, y order), which is the opposite of what most people expect. If you're extracting coordinates manually, swapping them is a common mistake that puts your points in the wrong hemisphere. If you need to convert GeoJSON to a format like TopoJSON, Shapefile, or KML — formats that preserve geometry in a different encoding — CocoConvert doesn't currently support those conversions. For geospatial format conversion with geometry intact, tools like GDAL's ogr2ogr command-line utility or the Mapshaper web tool are purpose-built for that job and handle it better than a general-purpose converter would. The GeoJSON-to-JSON conversion at /convert/geojson-to-json is specifically for the extract-properties use case. It does that one thing well.
Validating Your Output Before Using It Downstream
Once you have your output JSON file, spend two minutes validating it before feeding it into whatever system comes next. This catches conversion errors before they cause confusing failures downstream. First, confirm the structure. Open the file in a text editor or JSON viewer and check that the top level is an array (starts with [), each element is an object (starts with {), and none of the objects contain geometry or type keys from the original GeoJSON. A quick Ctrl+F search for 'coordinates' should return zero results. Second, check the record count. If your GeoJSON had 847 features, your output JSON array should have 847 objects. A mismatch means features were skipped — usually because of malformed input or null properties being dropped incorrectly. Third, spot-check a few records against the source. Pick feature index 0, feature index 423, and the last feature. Compare the property values in the output JSON against the same features in the original GeoJSON. If names, IDs, and numeric values match, the conversion is clean. For programmatic validation, JSONSchema is useful if you know what shape your properties should have. Tools like ajv (Node.js) or jsonschema (Python) let you define the expected keys and types and validate the entire output array in one pass. This is worth setting up if you're running this conversion regularly on updated datasets where input quality might vary. Finally, if the output file is going into a database, run a COUNT query after import and compare it to your expected record count. It takes 30 seconds and saves hours of debugging if something went wrong during the conversion or import step.