An EUDR GeoJSON validation error is a problem with the file, not with your farm. Five causes come up again and again: swapped latitude and longitude, a boundary exported as a line instead of an area, a single point standing in for a plot bigger than four hectares, a polygon ring that never closes, and a missing production country.
That’s the good news. Each of these checks is a stated rule with an exact fix.
Below is every check a file has to pass, what each error actually means, and the fix. The rules come from the European Commission’s EUDR GeoJSON File Description v1.5 (linked from the EUDR Information System page), the EUDR Operator API Reference v1.0 for API V3, Regulation (EU) 2023/1115 (EUDR) itself, and the GeoJSON standard, IETF RFC 7946.
What the EUDR actually requires of a location
Article 2(28) of Regulation (EU) 2023/1115 (EUDR) defines geolocation as “the geographical location of a plot of land described by means of latitude and longitude coordinates corresponding to at least one latitude and one longitude point and using at least six decimal digits; for plots of land of more than four hectares used for the production of the relevant commodities other than cattle, this shall be provided using polygons with sufficient latitude and longitude points to describe the perimeter of each plot of land.”
Two numbers to hold on to: six decimal digits, and four hectares. Almost every geometry error traces back to one of them.
Article 9(1)(d) of the same Regulation adds the part people miss. For products made using cattle, the geolocation refers to all the establishments where the cattle were kept — not to plots of land. For everything else in Annex I, it refers to the plots.
The checks that block a file
These are errors. A file with any of them is not in a state the EUDR Information System can work with.
| What fails | What it means | Where the rule comes from |
|---|---|---|
| Not a FeatureCollection | The top-level object must be a GeoJSON FeatureCollection with at least one feature. One production place per feature. |
File Description v1.5, §2 |
| Broken coordinate structure | Every coordinate is a [longitude, latitude] pair of finite numbers, nested to the depth its geometry type expects. Text, nulls, empty arrays and missing ring wrappers all fail. |
File Description v1.5; RFC 7946 §3.1.1 |
| Wrong geometry type | Type II files accept Point, MultiPoint, Polygon and MultiPolygon. Type I files also accept a GeometryCollection whose nested geometries are themselves valid. |
File Description v1.5, Type I and Type II geometry tables |
| Coordinates out of range | WGS84 (EPSG:4326) decimal degrees: longitude between −180 and 180, latitude between −90 and 90. | File Description v1.5 |
| Geometry collapses after truncation | Once coordinates are cut to six decimals, they must still be distinct points describing a real surface — no collapsed vertices, no adjacent duplicates, no exterior ring reduced to zero area. | File Description v1.5; API V3 rule GEO-CORD-10 |
| Ring not closed | The last coordinate pair of every polygon ring repeats the first, explicitly. | RFC 7946 §3.1.6 |
| Polygon has no area | A collinear or zero-area ring is not a production plot. | File Description v1.5; RFC 7946 §3.1.6 |
| Boundary crosses itself | Polygons must be non-self-intersecting. A figure-of-eight boundary is not a valid area. | File Description v1.5 |
| Polygon contains a hole | One contiguous production area per polygon. Interior rings are not accepted. | File Description v1.5 |
| Point used for a plot over 4 ha | A production place larger than four hectares needs a polygon. Points without an Area property default to 4 ha in the EUDR system. Cattle establishments are excepted. |
EUDR Art. 2(28); File Description v1.5 |
Point Area below the minimum |
The current V3 reference sets a minimum Point Area of 0.0001 hectares. |
API V3 Point Area business rule |
Area is not positive |
Where the Area property is present, it is a positive number of hectares. |
File Description v1.5 |
Missing or invalid ProducerCountry |
Type II files need ProducerCountry on every production place as a valid ISO 3166-1 alpha-2 code. Type I validates it when it is supplied. |
File Description v1.5, Type II feature properties |
The checks that warn rather than block
Worth reading before you upload. A warning means the file can proceed but something in it deserves a human decision.
| What warns | Why |
|---|---|
| More than six decimals | The current V3 API contract truncates coordinates to six decimals. Extra digits aren’t an error, but they aren’t preserved either. |
| Winding direction | RFC 7946 §3.1.6 puts exterior rings counterclockwise and holes clockwise. This is repairable without moving a single vertex. |
Point Area between 0.0001 and 0.1 ha |
The current V3 reference permits values from 0.0001 ha; the older EUDR Validation Rules v1.3 stated 0.1 ha. The two disagree, so this band gets flagged for review rather than silently accepted. |
Declared Area disagrees with the geometry |
When the stated hectares and the area measured from the polygon diverge substantially, one of the two is wrong. |
| Point without a known commodity | The cattle exception to the four-hectare rule can only be applied if the commodity is known. Without it, a point over four hectares can’t be confirmed as passed. |
You can check a file against every one of these right now. Clearlane’s free EUDR GeoJSON validator and repair tool runs the same cited rule profile in your browser, shows the plots on a map, and lets you download a repaired file. The file never leaves your browser.
Five causes worth checking first
Latitude and longitude are the wrong way round
GeoJSON orders a position as [longitude, latitude]. People say it the other way, spreadsheets store it the other way, and plenty of GPS apps export it the other way.
This is the nastiest one, because a swap often stays inside the valid ranges. A plot at 46.8 N, 7.2 E sits in Switzerland; write the pair the wrong way round and it lands at 7.2 N, 46.8 E, in central Somalia. Both are legal coordinates. The range check in the table above catches a swap only when the latitude value exceeds 90, so everything else looks fine until someone puts it on a map.
Fix: look at your plots on a map before you upload. Not at the numbers.
The boundary was exported as a line
Walk a field with a GPS app and you’ll often get a LineString back. Closing the loop visually doesn’t make it an area — a LineString isn’t in the accepted geometry list for either file type, and it has no interior, so nothing can measure its hectares.
Fix: re-export from the source as a polygon geometry. Don’t hand-edit the type field; the coordinate nesting is different for a Polygon (an array of rings) than for a LineString (an array of positions), so a renamed LineString fails the coordinate-structure check instead.
One point is standing in for a big plot
Article 2(28) of Regulation (EU) 2023/1115 (EUDR) is specific: over four hectares, non-cattle, you need a polygon with enough points to describe the perimeter.
Here’s the part that surprises people. A Point feature with no Area property doesn’t mean “size unknown” — the EUDR system treats it as four hectares. So an unsized point is a claim, not a blank. If the plot is bigger, the file is saying something untrue about it.
Fix: polygons for anything over four hectares. If the production place genuinely is four hectares or under, a point is fine, and so is a polygon.
The cattle exception is real but narrow. Article 9(1)(d) points cattle geolocation at the establishments where the animals were kept, so an establishment can be a single point regardless of its size. It applies to cattle. It is not a general escape from polygons.
Rings that don’t close, cross themselves, or have holes
Three separate errors, one underlying cause: the polygon came out of a tool that has a looser idea of “valid” than the EUDR file description does.
- Unclosed ring — RFC 7946 §3.1.6 requires the last position in a linear ring to repeat the first. Many exporters leave the closing pair off because renderers don’t need it. This one is a safe, meaning-preserving repair: add the duplicate pair back and no vertex has moved.
- Self-intersection — a boundary that crosses itself. Fixable by decomposition, but that changes the shape of the plot, so it should never happen without you looking at it.
- Interior rings — the file description wants one contiguous production area per polygon. Removing a hole changes the declared area, which again is your decision and not the tool’s.
Fix: repair the closure automatically; review the other two on a map yourself.
Precision that survives the file but not the truncation
Six decimals is the floor set by Article 2(28), and it’s also the ceiling in practice: the current API V3 contract truncates coordinates to six decimals under business rule GEO-CORD-10.
Usually harmless. Occasionally not. If two vertices of a small plot differ only in the seventh decimal, truncation merges them — and a ring that loses vertices can end up with adjacent duplicates or zero area. The file was valid before truncation and invalid after it.
Fix: apply the truncation yourself and re-check the geometry, rather than finding out at the portal. That’s what the post-truncation validity check exists for.
How big can the file be, and how many plots?
The Commission’s May 2026 Operator API V3 reference documents the limits for an assembled declaration: 100 commodities per declaration, 1,000 producers per commodity, 10,000 producers per declaration, 500 scientific-name and common-name pairs per commodity, and 2,000 grouping references. The assembled declaration’s geolocation data is capped at 25,000,000 bytes.
Those are limits on the declaration, not on your GeoJSON file as such. But if you’re consolidating hundreds of smallholder plots into one submission, the geolocation ceiling is the one you’ll meet first.
Type I or Type II — which am I looking at?
The Commission’s file description defines two variants, and the checks differ between them in two specific places:
| Type I | Type II | |
|---|---|---|
| Geometry types accepted | Point, Polygon, MultiPolygon, GeometryCollection |
Point, MultiPoint, Polygon, MultiPolygon |
ProducerCountry |
Validated when supplied | Required on every production place |
If a file passes for you and fails for your supplier, or the other way round, a variant mismatch is the first thing to rule out.
What a clean GeoJSON file still doesn’t prove
This matters more than any of the rules above, and it’s the thing most easily lost in the relief of a green tick.
A passing file means the supported format and data-quality checks passed. It does not mean the EUDR Information System has accepted a declaration, and it is not a legal or compliance verdict.
It doesn’t prove the goods are deforestation-free. It doesn’t prove they were produced in accordance with the relevant legislation of the country of production. It doesn’t complete your risk assessment or any mitigation the assessment calls for, and it doesn’t submit anything to the EUDR Information System. Under Article 3 of Regulation (EU) 2023/1115 (EUDR), all three conditions — deforestation-free, legally produced, and covered by a due diligence statement — have to hold. Geometry is the first step of one of them.
Satellite and remote-sensing evidence sits in the same category. It can support a risk assessment and can flag a change that needs a closer look. On its own it doesn’t prove the goods are deforestation-free, legally produced, or correctly linked to your supply chain.
The operator stays responsible for the full due diligence assessment and for the statement submitted to the authority.
Fix the file before it reaches the portal
Every rule in the tables above has its own page in the EUDR error catalogue, with the citation it comes from and what to do about it.
If you have a file in front of you right now, run it through the free EUDR GeoJSON validator and repair tool — it checks one file in your browser against this same cited rule profile, plots it on a map so a coordinate swap becomes obvious, records the repairs it can make safely, and hands you the corrected GeoJSON back. No account, no upload.
Clearlane prepares and validates the data. It does not file to the EUDR Information System or any registry on your behalf.
This article is educational guidance, not legal advice or a compliance verdict.