WGS84 & EPSG:4326-Geodetic systems explained
WGS84 (World Geodetic System 1984) is used by Smarty and is the globally accepted standard for geodesy—the study of Earth’s shape, size, and gravitational field—serving as the foundation for mapping and navigation systems worldwide. It defines a coordinate reference system that models the shape of the Earth, allowing for accurate location positioning across the globe.
The spatial geodetic reference datum code based on WGS84, known as EPSG:4326, is widely adopted by APIs, GIS platforms, and spatial data tools to ensure seamless integration and consistent, reliable geocoding across different systems and technologies.
Smarty understands your need for rooftop-accurate geocodes, no matter your area of expertise or which platform you’re using. Test them live, here, and now. Then, continue reading to learn more about WGS84/WGS 84, EPSG:4326, and geodetic systems in general.
In this article, you can expect to learn about these topics and ideas:
- The 3 most common coordinate reference systems
- Why geocoding standards matter
- EPSG code vs. SRID: What’s the difference?
- Use cases for developers
- How accurate is WGS 84?
- Implementing WGS84 in your app
- How Smarty supports geocoding standards
- Conclusion
- FAQs
The 3 most common coordinate reference systems
Coordinates are based on the WGS 84 standard, also known as the World Geodetic System 1984, which is used by GPS.
When working with geospatial data, choosing the right Coordinate Reference System (CRS) is important. Different CRSs are designed to meet the specific needs of various data types and use cases, and understanding how they work is crucial to ensuring your data is accurately represented.
For example, mixing GPS data in WGS84 with map data in UTM could lead to misalignment and errors, as the first is intended for global use and the second is intended for smaller, flat regional sections.
By selecting the appropriate CRS, you ensure your location data is precise and compatible across different platforms, leading to more reliable results and smoother data integration. The 3 main coordinate reference systems are World Geodetic System 1984 (WGS84), Universal Transverse Mercator (UTM), and North American Datum 1983 (NAD83).
What is the World Geodetic System 1984 (WGS84)
The WGS84 is a globally accepted system for positioning and navigation systems that assist with GPS capabilities. It defines the shape and size of the Earth, as well as how coordinates should be positioned across the globe.
What is EPSG:3857
EPSG:3857 is a projected coordinate reference system that uses the WGS84 datum as its basis. EPSG:3857 (Web Mercator) is commonly and widely used for web mapping.
It measures in meters instead of degrees like latitude and longitude. It’s easy to render, so it works well for zooming in and out and panning side to side on web applications and maps. There is the problem of distortion, though: areas near the poles are frequently distorted in scale and area, making places like Greenland look huge compared to Africa.
EPSG: The European Petroleum Survey Group (EPSG) is an organization that created a registry for various geodetic and coordinate reference systems. This registry assigns unique numeric codes to each system, and EPSG:4326 is the code for the WGS 84 geographic coordinate reference system.
What is EPSG:4326
EPSG:4326 is the EPSG registry code for the WGS84 geographic coordinate reference system (CRS), which uses latitude and longitude in decimal degrees, ordered latitude first and longitude second. It’s also the coordinate system used by Smarty! It’s a geographic 2D CRS that uses the WGS84 geodetic reference datum — a set of reference points defining the Earth’s shape, size, and orientation.
Although Smarty uses EPSG:4326, we use the DD (decimal degrees) format, as opposed to the DMS (degrees, minutes, seconds) format.
One way to write spherical coordinates (latitude and longitude) is using degrees, minutes, and seconds (DMS). Minutes and seconds range from 0 to 60.
For example, the geographic coordinate expressed in degrees-minutes-seconds for New York City is:
LATITUDE: 40 degrees, 42 minutes, 51 seconds N
LONGITUDE: 74 degrees, 0 minutes, 21 seconds W
But you can also express geographic coordinates in decimal degrees (DD). It’s just another way to represent that same location in a different format, and this is how Smarty chooses to represent our data.
For example, this is New York City in decimal degrees:
LATITUDE: 40.714
LONGITUDE: -74.006
What is UTM (Universal Transverse Mercator)
UTM is a particularly detailed geospatial tool used for spatial analysis and mapping purposes. Its focus is on reducing distortion by working with smaller areas at a time.
Often used in military and topographical analysis, each UTM zone is 6° of longitude wide. Zones are numbered from 1 to 60, starting at 180° west and moving eastward. Additionally, each zone has a latitude band (designated by a letter from C to X, excluding I and O) to help differentiate areas within each zone.
While it’s an excellent and precise tool for localized areas, as you move further away from the central meridian, distortion increases, which is a limitation if you intend to look at larger areas.
What is NAD83 (North American Datum 1983)
NAD83 is a geodetic datum used solely for mapping and surveying in North America. (A datum, as a reminder, is a reference system that defines the size, shape, and orientation of the Earth for the purpose of assigning coordinates to locations.)
Using the GRS80 ellipsoid to model the Earth’s shape, NAD83 provides a consistent coordinate reference frame for surveyors, cartographers, and GIS professionals. Over time, NAD83 has been updated through several realizations to incorporate modern GPS and satellite measurements, ensuring precise and reliable positioning throughout the continent.
Why geocoding standards matter
So, why even bother with geocoding standards? Having standards is never a bad thing 😉, but it really boils down to 3 main reasons. Having standards helps with: 1) avoiding mismatches in coordinate reference systems, 2) ensuring data consistency across platforms, and 3) supporting global location accuracy.
Avoiding mismatches in coordinate reference systems
As we just learned, different coordinate reference systems (CRSs) and datums define positions on the Earth in different ways. Mixing data from WGS84, UTM, or NAD83 without proper conversion can cause points to appear in the wrong place, leading to misaligned maps, inaccurate analysis, or even costly errors in navigation, logistics, and surveying.
Geocoding standards ensure that all data “speaks the same language,” so everything lines up correctly and we can make pinpoint-accurate, location-based decisions.
Ensuring data consistency across platforms
Just as medical teams rely on consistent data standards in their EHRs, insurance providers have consistent standards for policy flow, and fintech moguls follow specific processes to ensure data integrity, consistency across geocoding platforms keeps things running smoothly and accurately.
Location data often moves between software systems, APIs, and GIS platforms. Standards guarantee that coordinates, addresses, and geospatial information remain consistent across all of them. Without standards, the same location might be interpreted differently depending on the platform, which can break mapping applications, reporting dashboards, or integrations, and therefore, break the decisions you make for your business or organization based on that inaccurate information.
Supporting global location accuracy
A consistent geocoding standard allows locations to be accurately represented anywhere in the world. This is crucial for applications like shipping, international mapping, or global logistics, where even small errors can add up to big mistakes. Standards make sure coordinates are precise, reliable, and universally understood—whether you’re mapping a city block or tracking shipments across continents.
EPSG code vs. SRID: What’s the difference?
EPSG codes are identifiers from the EPSG (European Petroleum Survey Group) registry, which is a global catalog of coordinate reference systems (CRSs), datums, projections, and transformations. This is different from SRID because SRID stands for Spatial Reference System Identifier, used inside spatial databases to tag geospatial data with its CRS.
In short, EPSG codes are global identifiers for CRSs, but SRIDs are database-specific identifiers referencing CRSs, often aligned with EPSG codes. Both ensure that your geospatial data is interpreted correctly, whether it’s stored in a database, visualized on a map, or passed through an API, but SRIDs are specifically how databases and spatial systems keep track of which coordinate reference system each geometry uses, enabling accurate storage, queries, and transformations within those systems.
SRID as database reference
Think of an SRID as a tag on every point, line, or polygon that says, “interpret me this way.”
For example, in PostGIS, if you store the coordinates of the Empire State Building as POINT(-73.9857 40.7484) with an SRID of 4326, the database knows these numbers are latitude and longitude in WGS84.
This allows PostGIS (an extension of PostgreSQL that brings full GIS functionality into a relational database) to calculate distances, areas, or transform the point into another coordinate reference system accurately. Without the SRID, the database would have no frame of reference, and calculations could be completely wrong. MySQL works similarly, enforcing that geometries in a column match the SRID assigned to that column.
EPSG as a global registry
Another way to think of EPSG codes is like a global library of coordinate reference systems. The registry assigns every known projection, datum, or coordinate reference system a unique identifier, and by referencing an EPSG code, software and developers worldwide can understand exactly how coordinates are meant to be interpreted.
How they work in PostGIS, MySQL, and APIs
In practice, SRIDs in databases usually correspond to EPSG codes.
For instance, SRID 4326 in PostGIS…
is the same as EPSG:4326.
This alignment makes it easy to store, query, and transform geospatial data. When you query a PostGIS database for nearby points or perform a spatial join, the SRID ensures that all geometries are interpreted correctly.
Similarly, APIs that handle geocoding or mapping often ask you to specify an EPSG code to indicate the expected coordinate reference system for your input or output. For example, a mapping API might return a location in EPSG:4326 for geodetic latitude/longitude, but render map tiles in EPSG:3857 for display purposes.
Use cases for developers
So how do we use them anyway?
Obviously, we’ve touched on the more common use cases related to mapping APIs (ensuring that points, lines, and polygons appear in the right place on a map; think Google Maps), routing and navigation (connecting coordinate reference systems and routing engines to calculate accurate distances and directions/travel times; think Uber), and geospatial queries in databases (finding all restaurants within a 5-mile radius that sell corn dogs; think Yelp? Is that still around?).
It’s also worth noting the niche and advanced developer use cases that exist around WGS84 data.
Environmental and risk analysis
For example, developers working in data for environmental and risk analysis use CRSs and datums to model flood plains, wildfire zones, or pollution impact areas. Spatial statistics, heatmaps, or predictive models allow them to calculate true distance, areas, and density metrics. This same data is used by insurance agencies and real estate tycoons for accurate policy writing and investment risk assessment.
Asset and infrastructure management
Utility companies, telecommunications, and transportation apps track their networks of assets, like pipelines, power lines, or road sensors. Using the right CRS ensures asset overlays and geofencing work exactly as needed when combining local maps with global GPS datasets.
Indoor mapping and custom coordinate reference systems
Expansive areas like airports, malls, or factories might need to have developers define custom SRIDs to manage floor plans and assist with user indoor navigation. These often rely on transforming data from global datums like WGS84 to a local projected CRS that’s more meaningful for the building’s structural layout.
Geocoding and address standardization
Some of the best developers (in our humble opinion 😘) use WGS84, EPSG codes, and SRIDs to normalize and verify addresses across platforms of disparate data. Validation and accuracy for geocoding APIs are critical for fraud detection, customer verification, or accurate delivery routing, especially important when dealing with global data that has differing local standards and formatting.
How accurate is WGS 84?
The accuracy of WGS 84 depends on context:
Theoretical/GPS-based accuracy: Modern GPS receivers using WGS 84 can pinpoint locations to 2-5 meters under ideal conditions. WGS 84 itself is a reference frame—it doesn’t dictate GPS accuracy.
*GPS accuracy depends on hardware, signal conditions, and correction methods (like DGPS, WAAS, or RTK).(with Differential GPS or WAAS, this can improve to decimeter-level accuracy!)
**WGS 84 positional accuracy relative to the Earth’s crust is now on the order of centimeters in its most recent realizations (WGS 84(G2296), etc.), but most consumer GPS devices deliver 2–5 m accuracy without augmentation.
Earth model limitations: WGS 84, in this instance, treats the Earth as a smooth, slightly flattened sphere. This really works well for most purposes, but local features like mountains or any change in elevation can cause errors in 3D modeling or understanding elevation.
Time-based updates: WGS 84 has been refined and reworked over decades of existence to account for tectonic shifts and enhanced satellite technology’s measurements. However, even small, safeish movements in the Earth’s crust layer can affect absolute coordinates slightly over time.
This can affect accuracy because there isn’t a set “update WGS 84” schedule. It’s only adjusted as minor refinements occur continuously in technology’s accuracy.
Occasionally, we’ll see major realizations as larger revisions occur roughly every 10 years or so. Still, the actual realizations have been at irregular intervals (e.g., WGS84 (G730) in 1994, G873 in 1997, G1150 in 2002, G1674 in 2012, G1762 in 2013, and G2139 in 2021). Updates are triggered when enough new measurements justify a formal overhaul, but, again, those are few and far between.
Implementing WGS 84 in your app
When building an app that uses location data, you’ll want to make sure that all your coordinates are expressed in WGS 84 to maintain consistency across devices and platforms.
A few best practices include:
- Always store and transmit coordinates in decimal degrees (lat/lon).
- If using a local map projection for display, keep an internal WGS 84 copy for calculations or API calls.
- Validate incoming coordinates to ensure they fall within realistic ranges (latitude: -90 to 90, longitude: -180 to 180).
We’ll show you some examples and how to avoid a few pitfalls.
Setting EPSG:4326 in APIs and tools
Using EPSG:4326 ensures that your data is interpreted as standard lat/lon coordinates, avoiding misalignment with maps, databases, or other datasets.
Examples of how EPSG:4326 is used:
- PostGIS: Store geometries with ST_SetSRID(geom, 4326) to tag them as WGS 84.
- GeoJSON files: crs: { type: 'name', properties: { name: 'EPSG:4326' } } signals WGS84 coordinates.
- Smarty APIs: Requests for international or US address verification default to EPSG:4326, ensuring geodetic latitude/longitude outputs are globally consistent.
Example code snippets from Smarty’s API
Here’s a simple example showing how to use WGS84 coordinates with Smarty’s US Street API in Python:
# -*- coding: utf-8 -*-
import os
from smartystreets_python_sdk import SharedCredentials, StaticCredentials, exceptions, ClientBuilder
from smartystreets_python_sdk.us_street import Lookup as StreetLookup
from smartystreets_python_sdk.us_street.match_type import MatchType
def run():
# key = "Your SmartyStreets Key here"
# hostname = "Your Hostname here"
# We recommend storing your secret keys in environment variables instead---it's safer!
# for client-side requests (browser/mobile), use this code:
key = os.environ['SMARTY_AUTH_WEB']
hostname = os.environ['SMARTY_WEBSITE_DOMAIN']
credentials = SharedCredentials(key, hostname)
# for server-to-server requests, use this code:
# auth_id = os.environ['SMARTY_AUTH_ID']
# auth_token = os.environ['SMARTY_AUTH_TOKEN']
# credentials = StaticCredentials(auth_id, auth_token)
client = ClientBuilder(credentials).build_us_street_api_client()
# client = ClientBuilder(credentials).with_custom_header({'User-Agent': 'smartystreets (python@0.0.0)', 'Content-Type': 'application/json'}).build_us_street_api_client()
# client = ClientBuilder(credentials).with_http_proxy('localhost:8080', 'user', 'password').build_us_street_api_client()
# Uncomment the line above to try it with a proxy instead
# Documentation for input fields can be found at:
# https://smartystreets.com/docs/us-street-api#input-fields
lookup = StreetLookup()
lookup.input_id = "24601" # Optional ID from your system
lookup.addressee = "John Doe"
lookup.street = "1600 Amphitheatre Pkwy"
lookup.street2 = "closet under the stairs"
lookup.secondary = "APT 2"
lookup.urbanization = "" # Only applies to Puerto Rico addresses
lookup.city = "Mountain View"
lookup.state = "CA"
lookup.zipcode = "94043"
lookup.candidates = 3
lookup.match = MatchType.INVALID # "invalid" is the most permissive match,
# this will always return at least one result, even if the address is invalid.
# Refer to the documentation for additional Match Strategy options.
# Uncomment the below line to add a custom parameter
# lookup.add_custom_parameter("parameter", "value")
try:
client.send_lookup(lookup)
except exceptions.SmartyException as err:
print(err)
return
result = lookup.result
if not result:
print("No candidates. This means the address isn’t valid.")
return
first_candidate = result[0]
print("There is at least one candidate.")
print("If the match parameter is set to STRICT, the address is valid.")
print("Otherwise, check the Analysis output fields to see if the address is valid.\n")
print("ZIP Code: " + first_candidate.components.zipcode)
print("County: " + first_candidate.metadata.county_name)
# default to EPSG:4326, ensuring latitude/longitude outputs are globally consistent
print("Latitude: {}".format(first_candidate.metadata.latitude))
print("Longitude: {}".format(first_candidate.metadata.longitude))
# print("Precision: {}".format(first_candidate.metadata.precision))
# print("Residential: {}".format(first_candidate.metadata.rdi))
# print("Vacant: {}".format(first_candidate.analysis.dpv_vacant))
# Complete list of output fields is available here: https://smartystreets.com/docs/cloud/us-street-api#http-response-output
if __name__ == "__main__":
run()This snippet retrieves latitude and longitude in WGS84, ready to use in your app or mapping layer.
Coordinate transformations and pitfalls
Sometimes, depending on your use case or business logic, you’ll need to convert the WGS84 coordinates to another CRS for mapping, analysis, or compatibility with a GIS tool. Many GPS receivers provide ellipsoidal height by default, but if you need real-world elevation for mapping, construction, or risk modeling, you have to convert it to orthometric height using geoid models.
While transformations are straightforward with libraries like Proj4js or PostGIS ST_Transform, there are some pitfalls to be aware of:
- Precision loss: Projecting to a system like Web Mercator can slightly distort distances, especially near the poles.
- SRID mismatch: Mixing WGS84 with another CRS without proper transformation will cause misaligned data.
- Height/altitude data: WGS84 includes ellipsoidal height (sometimes called geodetic height, meaning the vertical distance from a point on Earth’s surface to the reference ellipsoid), which may not match local vertical datums used for terrain or construction projects.
- Batch processing caution: When transforming large datasets, always verify outputs on sample points to catch unexpected shifts.
*Tip: Always keep an internal copy of coordinates in EPSG:4326 and only transform when necessary for visualization or calculations. This preserves accuracy, consistency, and interoperability across apps and APIs.
How Smarty supports geocoding standards
Smarty has taken many deliberate steps to ensure that WGS84 standards are supported so that your address data is the best it can be. Here’s a quick breakdown for you to reference if you’re considering Smarty’s geocoding products or services:
- Adherence to Global CRSs and EPSG codes: By default, all coordinates will return in EPSG:4326, ensuring your geospatial data is interoperable across mapping platforms, GIS software, and other geospatial tools while respecting country-specific formats required by local postal standards.
- Consistent coordinate reference use in APIs: Whether you’re using Smarty’s US or international APIs, a structured output that includes standardized lat/long coordinates and valuable metadata returns, making integration into applications, databases, or mapping layers a cinch.
- Support for SRIDs and database standards: Smarty explicitly references EPSG codes and SRIDs in our documentation and examples because we want to help developers store, query, and visualize geospatial data without misalignment.
- Address and geocoding accuracy practices: Smarty emphasizes high match rates, rooftop-level geocoding, and validated address data, which are essential for location intelligence. By aligning our outputs with recognized ellipsoids, datums, and reference systems, Smarty ensures that your coordinates are standardized and geodetically accurate—not to mention developer-friendly with clear example code, SDKs, and REST API endpoints.
Conclusion
Understanding WGS84, EPSG:4326, and geodetic systems is essential for anyone working with location data, whether for mapping, navigation, or geospatial analysis. WGS 84, built on a reference ellipsoid and maintained through continuous GPS satellite measurements, provides a globally consistent framework that powers modern global positioning systems.
By aligning your coordinates with EPSG:4326, you ensure that your geospatial data remains accurate, interoperable, and compatible across GIS platforms, APIs, and databases.
From rooftop-accurate geocoding to environmental modeling, asset management, and indoor navigation, adhering to geodetic standards prevents mismatches, supports global location accuracy, and simplifies integration across applications.
Leveraging these standards in your systems not only improves geocoding precision but also future-proofs your location-based operations in an increasingly interconnected world.
By implementing WGS84 and EPSG:4326, or using awesome tools like Smarty, who build that in for you, you’re not just using coordinates—you’re tapping into a robust geodetic system that forms the backbone of GPS satellites, global positioning systems, and accurate mapping worldwide.
With this foundation, your location data can confidently guide decisions, optimize logistics, and unlock insights at a global scale.
For the best geocoding API, try out Smarty’s US Rooftop Geocoding API, US Reverse Geocoding API, or QGIS Geocoding Plugin live and absolutely free to see how it all comes together.
FAQs
Why do Smarty geocodes have only 5 or 6 digits to the right of the decimal point?
Let’s answer this in a chart that highlights the precision of our geocodes and explains why we only return 5-6 digits. To illustrate what each digit means, we’ve broken the precision down by digit. Note: This is an estimate, as it changes slightly as you move around the globe.
41.12345
^ 690 mi, 1,111 km
` ^ 69 mi, 111 km
` ^ 6.9 mi, 11.1 km (36,432 ft)
` ^ .69 mi, 1.11 km (3,643 ft)
` ^ .069 mi, .111 km (364.3 ft)
` ^ .0069mi, .0111 km (36.43 ft)
` ^ .00069mi, .00111 km (3.643 ft)
What does WGS84 stand for?
WGS 84 or WGS84 stands for World Geodetic System 1984. It refers to the globally recognized reference system we use to maintain consistency in mapping and geocoding when examining Earth.
What is the difference between GPS and WGS84?
GPS, or Global Positioning System, is a satellite network that provides real-time location and time data anywhere on Earth.
Geodetic WGS84, or World Geodetic System 1984, is the coordinate reference system that GPS uses to translate the satellite signals into precise lat/long coordinates and altitude.
Basically, GPS measures your position; WGS84 defines the grid used to map that position accurately.
What is the difference between NAD83 and WGS84?
NAD83, or North American Datum 1983, is only a regional coordinate reference system that is optimized for North America, slightly offset from the WGS84 to better match the continent’s shape.
WGS84 is global, and that’s how they differ.
What is a geodetic datum?
This is a fancy way of saying a reference system for maps and GPS. A geodetic datum tells your device exactly where “zero” is on Earth and how to measure locations from that point. Think of it as the invisible framework that keeps all maps and coordinates aligned.
What is a geodetic reference?
Geodetic reference systems are the broader framework that includes one or more datums, plus the rules for measuring positions in the geodetic datum. What is the International Terrestrial Reference Frame?
The International Terrestrial Reference Frame (ITRF) is basically the global “master” copy of our map for exact locations on Earth. WGS84 is based on ITRF (aligned with minor tweaks for GPS use).
What is the International Terrestrial Reference Frame?
The International Terrestrial Reference Frame (ITRF) is basically the global “master” copy of our map for exact locations on Earth. WGS84 is based on ITRF (aligned with minor tweaks for GPS use).