SHP File Documentation

---

Technical details

Feature	Value
Full name	Esri Shapefile
File extension	.shp
MIME type	application/x-esri-shape
Format type	Binary geospatial vector geometry
Developer	Esri (Environmental Systems Research Institute)
Introduced	Early 1990s; technical description published 1998
Specification	ESRI Shapefile Technical Description (1998 white paper)
Open standard	Partial (published vendor description)
Header length	100 bytes, fixed
Byte order	Mixed — big-endian file code and length; little-endian version, shape type and records
Magic number	00 00 27 0A (file code 9994, big-endian) at offset 0
Version	1000 (bytes 28–31)
Geometry only	Yes — no attributes or projection in the .shp itself
Required siblings	.shx (index), .dbf (attributes)
Recommended sibling	.prj (coordinate reference system, WKT)
Optional siblings	.cpg (encoding), .sbn/.sbx (spatial index)
File size limit	2 GB per .shp and per .dbf
Modern successor	GeoPackage (.gpkg, single SQLite file)
Related extensions	.shx, .dbf, .prj, .gpkg, .geojson, .kml
Specification URL	esri.com/.../shapefile.pdf

What is a SHP file?

A .shp file is, in the overwhelming majority of cases, an Esri Shapefile, the most widely used vector format in the GIS (Geographic Information System) world. Esri, the company behind ArcGIS, developed it for its ArcView product in the early 1990s and published an open technical description in July 1998, which is why an enormous range of tools read and write it despite it being a vendor format. A shapefile stores geographic features as vector geometry: points (wells, addresses), lines (roads, rivers) or polygons (parcels, lakes, administrative boundaries).

The defining quirk of the format is that a “shapefile” is not one file. The .shp holds only geometry. It must travel with companion files in the same folder, at minimum a .shx index and a .dbf attribute table, and almost always a .prj that records the coordinate system. Hand someone a lone .shp and it will open empty or not at all. The sections below cover the 100-byte header field by field, the mixed-endian layout that catches out first-time parsers, how records encode each geometry type, and why the sidecar files are mandatory rather than optional.

The 100-byte header, field by field

Every .shp begins with a fixed-length header of exactly 100 bytes. It contains nine 4-byte integer fields followed by eight 8-byte double-precision fields. What makes it unusual is that the header is not consistently one byte order: some fields are big-endian and some are little-endian, a legacy of the format’s origins.

bytes  0- 3  int32  BE  file code = 9994  (0x0000270A)
bytes  4-23         BE  five unused int32 fields (all zero)
bytes 24-27  int32  BE  file length, in 16-bit words, whole file incl. header
bytes 28-31  int32  LE  version = 1000
bytes 32-35  int32  LE  shape type (applies to every record)
bytes 36-67  double LE  bounding box: Xmin, Ymin, Xmax, Ymax
bytes 68-99  double LE  Zmin, Zmax, Mmin, Mmax  (Z and measure ranges)

The first four bytes are the file code 9994, stored big-endian as 00 00 27 0A; that is the file’s signature. The file length at bytes 24–27 is expressed in 16-bit words, so the true byte count is that value times two, and it too is big-endian. From byte 28 onward the header switches to little-endian: the version (always 1000), the shape type, and then the minimum bounding rectangle of all features (Xmin, Ymin, Xmax, Ymax) as doubles, followed by the Z and M (measure) ranges. The shape type in the header applies to the whole file: with the sole exception of null shapes, every record in a shapefile must be the same geometry type.

Shape type codes

The shape type at bytes 32–35 is an integer drawn from a fixed enumeration. It appears once in the header and is repeated at the start of every record. The codes are deliberately non-contiguous, grouped by dimensionality: the plain 2D types are low numbers, the Z-enabled (3D) types are in the teens, and the measured (M) types are in the twenties.

Code	Shape type
0	Null shape (a placeholder with no geometry)
1	Point
3	PolyLine
5	Polygon
8	MultiPoint
11	PointZ
13	PolyLineZ
15	PolygonZ
18	MultiPointZ
21	PointM
23	PolyLineM
25	PolygonM
28	MultiPointM
31	MultiPatch

Coordinates throughout are stored as IEEE 754 double-precision floating point, little-endian, which is why shapefiles preserve full positional precision but are relatively large on disk. A Z type adds an elevation value per vertex; an M type adds a “measure” value (often a route distance or time) per vertex.

Records: the header and the geometry

After the 100-byte header the file is a sequence of variable-length records, each describing one feature. Every record has an 8-byte record header followed by the shape’s geometry.

record header (8 bytes)
  int32  BE  record number   (1-based, sequential)
  int32  BE  content length   (in 16-bit words)
record contents
  int32  LE  shape type       (repeated; 0 = null)
  ...        geometry bytes for that type

The record number and content length in the record header are big-endian, matching the file-code convention, while the geometry that follows is little-endian. A Point record is simply the shape type then an X and a Y double. A PolyLine or Polygon record is more involved: it carries a bounding box, a count of parts and points, an array of indices marking where each part begins, and then the flat array of X,Y pairs. A Polygon’s rings follow a winding rule: an outer ring runs clockwise and an inner ring (a hole) runs counter-clockwise, which is how the format distinguishes a hole from a separate island without a separate flag.

Why the .shx, .dbf and .prj siblings are mandatory

The single most common shapefile problem, “it won’t open” or “it opens but there is no data”, comes down to missing companion files, so it is worth being precise about what each one does. The geometry in the .shp is deliberately incomplete on its own.

File	Required?	Contents
.shp	—	the feature geometry (this file)
.shx	required	shape index: the byte offset and length of each record in the .shp, so a reader can seek directly to feature n
.dbf	required	a dBASE table with one row of attributes per feature (names, values, categories)
.prj	recommended	the coordinate reference system as Well-Known Text; without it the numbers are just coordinates with no known projection
.cpg	optional	the character encoding of the .dbf (e.g. UTF-8)

The link between .shp, .shx and .dbf is positional: feature number n in the geometry corresponds to row n in the attribute table, with the index giving the reader a fast lookup into the geometry. The three files must share the same base name and sit in the same folder. Because they are so easy to separate, shapefiles are almost always distributed as a single ZIP containing the whole set, and the correct advice when a shapefile fails is to ask the sender for the missing .dbf/.shx rather than to try to repair the .shp.

Format limits and the GeoPackage successor

The shapefile carries hard limits that reflect its age. Each .shp and each .dbf is capped at 2 GB, because file offsets are 32-bit. The dBASE attribute table restricts field names to 10 characters and has awkward encoding behaviour, so long column names get silently truncated on export, a real data-loss trap. Field types are limited, and there is no support for storing multiple geometry types or a proper null in the same layer.

The modern replacement is the GeoPackage (.gpkg), a single SQLite database file that holds geometry, attributes, projection and indexes together, removing both the multi-file fragility and the size and naming limits. For lightweight and web use, GeoJSON and KML serve the same role in a single text file. All of these convert to and from shapefile with GDAL/OGR (ogr2ogr) or the free desktop app QGIS, which read the exact header and record structure described above.

A note on the other .shp: AutoCAD shape files

A small minority of .shp files are not GIS data at all. In AutoCAD and 3ds Max, .shp is a plain-text shape and font definition file: a compiled-from source description of vector glyphs and symbols used to build SHX fonts and custom line types. It is unrelated to the Esri Shapefile and is opened inside those CAD programs, not in GIS software. You can tell the two apart instantly by the first bytes: an Esri Shapefile is binary and starts with 00 00 27 0A, while an AutoCAD shape file is readable ASCII beginning with lines like *UNIFONT or numbered shape definitions. If a .shp opens as plain text in an editor, it is the CAD kind; if it is binary with that file-code signature, it is the GIS shapefile this article describes.

References

• Esri — ESRI Shapefile Technical Description (1998)
• GDAL/OGR — ESRI Shapefile driver
• Library of Congress — ESRI Shapefile format

Feedback

Was this page helpful?

Yes No

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.