How to Convert GeoJSON to JSON (Strip Geometry, Keep Properties)
What GeoJSON Actually Contains (and Why It's More Than You Need)
GeoJSON is just JSON, but with a highly specific, and often bulky, structure. Every file typically wraps your data in a `FeatureCollection` which contains an array of `Feature` objects. Each `Feature`, in turn, has two main parts: `geometry` and `properties`. The `geometry` block is where all the spatial data lives—coordinate arrays, shape types like Point or Polygon, and complex coordinate rings that can run for thousands of lines. The `properties` block is what you usually care about: the actual attribute data like names, IDs, population counts, or timestamps tied to each shape. That structure becomes a problem when you need to pass the data to a system that doesn't speak 'map'. Imagine you've exported a dataset of all 4,200 U.S. county boundaries from a GIS tool. The resulting GeoJSON file could easily be 18 MB, with each county polygon defined by thousands of coordinate pairs. If your goal is just to use the county name, FIPS code, and population in a report or API, you're dragging around 95% dead weight. That geometry is just noise. Worse, some parsers will flat-out reject a file because they don't recognize the geospatial keys. For these non-spatial uses, stripping the geometry isn't losing data; it's just smart data preparation.
The Structure Difference: GeoJSON vs. Plain JSON
Let’s get specific about the transformation. Here's a minimal GeoJSON `Feature` you might start with: { "type": "Feature", "geometry": { "type": "Point", "coordinates": [-87.6298, 41.8781] }, "properties": { "city": "Chicago", "population": 2696555, "timezone": "America/Chicago" } } After stripping the geometry, your target is the clean, simple JSON object nested inside the `properties` key: { "city": "Chicago", "population": 2696555, "timezone": "America/Chicago" } When your input is a `FeatureCollection` (a file with multiple features), the goal is to produce a single JSON array containing just the property objects from each feature: [ { "city": "Chicago", "population": 2696555, "timezone": "America/Chicago" }, { "city": "Houston", "population": 2304580, "timezone": "America/Chicago" } ] This is the format that most APIs, spreadsheet importers, and database loaders are built to understand. Anyone who has debugged a failing API call knows the frustration of a parser choking on unexpected top-level keys like `geometry` or `type`. The final result is a clean JSON array, ready to work with almost any tool. A critical detail: what if a feature has a `null` value for its `properties`? This is valid GeoJSON. A good converter will produce an empty object `{}` for that feature instead of crashing or, worse, silently skipping it. Sloppy converters fail this test all the time.
Converting GeoJSON to JSON with CocoConvert
For a fast, no-code solution, CocoConvert's GeoJSON-to-JSON converter at /convert/geojson-to-json is designed for exactly this job. The process is simple. You upload your `.geojson` or `.json` file (it accepts both extensions, since GeoJSON often uses `.json`), select your options, and download the stripped-down result. The converter is ruthless by default. It finds the `features` array, grabs the `properties` object from every single feature, and stitches them into a clean JSON array. The `geometry` key, the `type` key, and the `FeatureCollection` wrapper all get left behind. If your file contains just a single `Feature` instead of a collection, the output will be a single JSON object, not an array. CocoConvert handles files up to 50 MB on the free tier, which is plenty for most datasets with fewer than 10,000 features. But if you have a massive file like a state-wide road network (which can easily be 200 MB or more), you'll need to use a command-line tool, which we cover next. For privacy, the converter processes files on the server but doesn't store your data after your session, an important detail if your attributes include sensitive information like personal identifiers. By default, the downloaded file will have a `.json` extension. The settings panel gives you more control, letting you specify a custom filename or get indented, human-readable output instead of a minified one-liner.
Command-Line Alternatives for Large Files or Automation
When you're dealing with files over 50 MB or need to automate this conversion in a script, the command line is your friend. You have two main weapons of choice: `jq` and Python's built-in `json` module. For pure JSON transformation, nothing beats `jq` for speed and simplicity: jq '[.features[].properties]' input.geojson > output.json This one-liner does exactly what the web tool does: it iterates over each feature, plucks out the `properties` object, and wraps the results in a JSON array. `jq` is easily installed on any major OS (like `brew install jq` on macOS or `apt install jq` on Debian/Ubuntu) and can chew through gigabyte-sized files without flinching because it streams the data instead of loading it all into memory. If your feature `id` is important (in GeoJSON, it lives alongside `properties`, not inside it), you can merge it in: jq '[.features[] | {id: .id} + .properties]' input.geojson > output.json When you need more logic, Python is the answer: 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 short script gives you total control to filter features, rename keys, or handle weird edge cases before writing the output. Best of all, the `json` module is part of Python's standard library, so there's nothing extra to install. Let me be direct with my recommendation: Use CocoConvert when you have one file and want a result in 30 seconds without touching code. Use `jq` or Python when you're automating a data pipeline or processing hundreds of files.
Handling Edge Cases That Break Naive Converters
Real-world GeoJSON is often messier than the clean examples in the specification. Here are the common gotchas that can break a naive converter. **Null geometry:** You'll frequently encounter features with `"geometry": null`. These are perfectly valid, often representing records that simply lack location data. A robust converter must still extract their properties, not discard the entire feature. The `jq` and Python methods shown earlier handle this correctly. **Nested properties:** The `properties` object itself can contain nested JSON objects, like `"properties": {"address": {"street": "Main St"}}`. Stripping the geometry does not flatten these nested structures; they are preserved as-is. If you need a completely flat structure (for a CSV, for instance), that's a separate transformation you'll need to perform. **Inconsistent keys:** It's common for some features in a collection to have a `"name"` key while others don't. The resulting JSON array will simply have objects with different shapes. This is valid JSON, but it can trip up strongly-typed systems. CocoConvert faithfully extracts what's there; it won't try to normalize the schema for you. **`GeometryCollection`:** Some files use a `GeometryCollection` type, which has a different structure from the standard `FeatureCollection`. Many tools, including CocoConvert, expect a `FeatureCollection` and may fail if they encounter a `GeometryCollection` at the top level. **Encoding problems:** This is a classic GIS data headache. The GeoJSON spec mandates UTF-8 encoding, period. But files exported from older software can sometimes contain Latin-1 or Windows-1252 characters. This will cause parsing errors. You must fix the encoding upstream using a tool like `iconv` before attempting conversion.
When You Should Keep the Geometry (and Convert Differently)
While stripping geometry is great for data-only workflows, sometimes it's absolutely the wrong move. There are plenty of times you need to keep the spatial data, just in a different form. If you're feeding data to a web mapping library like Leaflet or MapboxGL, stop. Do not convert anything. Both libraries consume GeoJSON natively, so converting to plain JSON would remove the very coordinates they need to draw your map. Sometimes you need the coordinates, just in a different shape—like a flat array of `{lat, lng, name}` objects for a custom chart. That's a reshaping task, not a geometry strip. `jq` is perfect for this: jq '[.features[] | {lat: .geometry.coordinates[1], lng: .geometry.coordinates[0], name: .properties.name}]' input.geojson > output.json Pay close attention to the coordinate order here. GeoJSON is strictly `[longitude, latitude]`, or (x, y). This is the opposite of what many people and systems expect. Getting this wrong is the most common mistake when manually handling GeoJSON coordinates, and it has the hilarious and frustrating effect of putting your data in the wrong hemisphere. If your goal is to convert GeoJSON to another geospatial format like TopoJSON, Shapefile, or KML, you need a different tool. CocoConvert doesn't do these geometry-preserving conversions. For that, you should use a purpose-built tool like the command-line powerhouse `ogr2ogr` (from GDAL) or the excellent Mapshaper web tool. They are the right tools for that job. Our GeoJSON-to-JSON tool at /convert/geojson-to-json is laser-focused on one task: extracting properties. It does that one thing, and does it well.
Validating Your Output Before Using It Downstream
Before you feed your shiny new JSON file into a downstream system, take two minutes to validate it. This simple step can save you from hours of debugging confusing failures later. Pop the file open in a text editor. Is the top level an array (it starts with `[`)? Is each element an object (starting with `{`)? Critically, do you see any `geometry` or `type` keys? You shouldn't. A quick search for the string 'coordinates' should find zero matches. Next, check the record count. If your input GeoJSON had 847 features, your output JSON array must have exactly 847 objects. If the numbers don't match, the converter dropped features, likely due to malformed input or incorrect handling of nulls. Now, spot-check the data itself. Compare the property values for the first, last, and one random middle record in your new JSON against the original GeoJSON file. If the names, IDs, and numbers all line up, you can be confident the conversion was clean. For automated pipelines, use JSONSchema. Tools like `ajv` for Node.js or `jsonschema` for Python allow you to programmatically verify that every object in your array has the keys and data types you expect. This is essential for any process that runs regularly on changing data. And one last thing: if the data is heading for a database, run a `COUNT` query on the table after the import. Does the row count match what you expected? This 30-second check is the ultimate confirmation that the entire chain—conversion and import—worked perfectly.