Polygon Formats. WKT vs WKB vs GeoJSON vs Shapefile vs KML and KMZ

If you work with polygons, you will constantly run into the same question.
Which format should I use for storage, for sharing, and for GIS tools.

This guide explains the practical differences between:

• WKT.
• WKB.
• GeoJSON.
• Shapefile.
• KML and KMZ.

It also shows safe conversion habits using ClearSKY Polygon Tools.

---

Quick pick. Which format should you use

Use this if you just want the answer.

• Use GeoJSON for web apps and APIs. It is readable, common, and easy to validate.
• Use WKT for copy paste and debugging. It is readable and easy to paste into a validator.
• Use WKB for compact database storage and binary transport. Convert it to WKT or GeoJSON when you need to inspect it.
• Use Shapefile when you must support older GIS workflows. Expect extra files and format limits.
• Use KML or KMZ for Google Earth style sharing. KML is strict about CRS and is mostly for display.

If you are not sure, start with GeoJSON and keep WKT around for debugging.

---

What each format is good at

WKT. Best for copy paste, databases, and debugging

WKT is a text representation of geometry, like POLYGON((...)).

• Good for. Databases, SQL, logs, small geometry snippets, quick sharing in chat.
• Not good for. Storing properties, styling, or large datasets.
• Common gotcha. People copy only the geometry and forget attributes. That might be fine, but it surprises users.

When WKT shines, you can paste one geometry into WKT Validator and immediately see what is wrong.

WKB. Best for compact storage and transport

WKB is a binary representation of geometry. You will often see it as hex text or base64 in logs and APIs.

• Good for. PostGIS and other spatial databases, compact storage, fast transport between services.
• Not good for. Humans. You cannot eyeball WKB and understand the shape.
• Common gotchas.
  • WKB can be plain WKB or EWKB. EWKB may include SRID and extra flags.
  • People mix encodings. Some systems send hex. Others send base64.
  • Properties are not included. WKB is geometry only.

When WKB shines, you decode it in WKB Viewer, validate the geometry, then export WKT or GeoJSON.

GeoJSON. Best for web, APIs, and modern tooling

GeoJSON is JSON. It supports geometry plus properties and FeatureCollections.

• Good for. Web maps, APIs, browser tooling, storing attributes, version control diffs.
• Not good for. Very large datasets without compression, or workflows that require strict schema.
• Common gotcha. GeoJSON assumes WGS84 lon, lat in most web contexts. If you feed it projected coordinates, it will still parse, but it will look wrong on a map.

When GeoJSON shines, you can validate and preview it quickly, then convert it to the format you need.

Shapefile. Best for legacy compatibility

Shapefile is old, but it is still everywhere. It is not one file. It is a set of files.

• Good for. Compatibility with older GIS stacks and government workflows.
• Not good for. The web, long field names, Unicode edge cases, or keeping everything in one file.
• Common gotchas.
  • It is multiple files. A missing sidecar file can break it.
  • Attribute limits exist. Field name length and type limits are real.
  • CRS is stored in a separate .prj file. If it is missing, people guess.

When Shapefile shines, it is because someone upstream only accepts it.

KML and KMZ. Best for Google Earth sharing and visual review

KML is XML and KMZ is a zipped KML bundle. KML is usually used for display and sharing.

• Good for. Sharing polygons with non technical users, quick review in Google Earth.
• Not good for. Heavy analysis pipelines, strict topology workflows, or mixed CRS data.
• Common gotcha. KML is typically interpreted as WGS84 lon, lat. If your coordinates are not lon, lat, it will be wrong.

KMZ is often better than KML because it is one file, and it can include related assets.

---

What breaks conversions in real life

Most conversion failures are not about the format. They are about the geometry.

Common failure modes.

• Ring is not closed.
• Ring has too few vertices.
• Ring has zero area.
• Ring self intersects.
• Holes are outside the outer ring.
• Coordinates are flipped, or the CRS is wrong.

If you validate first, conversions become boring.

---

A safe conversion workflow in ClearSKY Polygon Tools

This is the workflow that avoids surprises.

1. Validate first.
2. Fix geometry issues in the Editor if needed.
3. Convert to the target format.
4. Validate again after conversion, if the target system is strict.

Step 1. Validate

• Use WKT Validator for WKT input.
• Use GeoJSON Validator for GeoJSON input.

If you see errors, do not convert yet. Fix first.

Step 2. Fix in the Editor

The Editor is for decisions that no validator should guess for you, like:

• Which lobe to keep in a bowtie.
• Whether a hole should become its own polygon.
• Whether a shape should be rebuilt cleanly.

Step 3. Convert

Use Universal Converter when you just want a reliable conversion path between formats.

Step 4. Confirm the output

• Preview the output.
• Check bounds, area, and vertex count.
• Check that holes still look like holes.
• Check that coordinates still look like lon, lat if you are using web formats.

---

Format tips that save you time

• Keep a WKT copy for debugging. It is the fastest way to share a single polygon in a ticket or chat.
• Use WKB for compact database storage and transport. Convert it to WKT or GeoJSON when you need to inspect it.
• Store working datasets as GeoJSON during editing. It plays well with git, and it keeps properties with geometry.
• Use KMZ instead of KML when you can. One file is harder to mess up than many.
• Treat Shapefile as a delivery format. Do not treat it as a source of truth unless you must.

---

FAQ

›Which format should I pick as a 'source of truth'?

In most modern workflows, GeoJSON is a good default source of truth. It keeps properties with geometry, it is readable, and it is easy to validate. If your system is database first, WKB and EWKB are common for geometry storage, and WKT is a practical option for readability.

›Why does Shapefile cause so many surprises?

It is a legacy format with limits, and it is not one file. Missing sidecar files, attribute constraints, and CRS handling cause most of the pain. Shapefile is still useful, but you should expect friction.

›Is KML always EPSG 4326?

KML is generally interpreted as WGS84 lon, lat in most viewers. If you feed projected coordinates, it will usually look wrong. If you are unsure, validate and preview before sharing.

›Is WKT better than GeoJSON for performance?

For a single geometry, WKT can be smaller and simpler. For structured datasets with properties, GeoJSON is usually easier to work with and safer to exchange. For very large datasets, you will eventually want proper tiling or compression regardless of format.

›Should a validator fix my geometry automatically?

A validator should detect and explain issues. Light, deterministic fixes can be offered as options, but real repairs often require human intent. If a fix changes topology, it belongs in an editor step where you can see the result.