ECEF to geodetic converter

What ECEF XYZ means and what the response returns

In the WGS84 Earth-centered Earth-fixed frame, the origin sits at the Earth's center of mass, the Z axis points toward the Conventional Terrestrial Pole, the X axis lies in the equatorial plane toward the Greenwich meridian, and the Y axis completes a right-handed triad ninety degrees east of X. A surface point on the equator at zero longitude has X near the semi-major axis about six million three hundred seventy-eight thousand one hundred thirty-seven meters and Y and Z near zero; a point near the North Pole has large positive Z and small equatorial radius p equals the square root of X squared plus Y squared. Geodetic latitude is the angle between the equatorial plane and the ellipsoidal normal, not the geocentric angle from the center to the point, so converting XYZ requires the WGS84 flattening and an iterative or closed-form latitude solver rather than a single arctangent of Z over p. This tool returns latitude and longitude in degrees, ellipsoidal height in meters, short lat, lon, and h aliases, the echoed X Y Z inputs, the datum tag WGS84, ellipsoid constants a, inverse flattening, b, and e squared, a method tag for the iterative ECEF path, the iteration count used, the rounding precision, and a compact formula string for documentation. There is no reverse address lookup, no magnetic declination, and no network call: the engine either computes a finite geodetic triple or rejects the input with invalid_input. Rejected cases include missing coordinates, non-finite numbers, the exact origin zero zero zero which has no unique latitude or longitude, and an out-of-range precision field.

How fields are read and how the iterative WGS84 solve stays reproducible

Computation takes longitude as atan2 of Y and X, forms the equatorial radius p, seeds latitude from a geocentric estimate corrected by one minus eccentricity squared, then iterates latitude as atan2 of Z plus e squared times N times sin of latitude over p, where N is the prime vertical radius a over the square root of one minus e squared sin squared latitude. Height is p over cos latitude minus N, with a pole-safe branch that uses Z when cosine is tiny. The preferred fields are x, y, and z for the ECEF meters triple, with aliases X and ecef_x, Y and ecef_y, and Z and ecef_z so spreadsheets, query strings, and typed forms can reuse the same contract without renaming columns. Each coordinate may arrive as a JSON number or as a decimal string including scientific notation when finite; empty strings, Infinity, and NaN are rejected so a bad cell does not become a wrong meridian. An optional precision field, with aliases decimals and dp, chooses how many decimal places to expose for latitude, longitude, and height, defaulting to ten and capped at fifteen so JSON goldens stay stable across runtimes. Pair the free browser run on this page with the priced API when you need the identical mathematical result inside an automated pipeline without re-implementing WGS84 ECEF yourself.

Where ECEF to geodetic conversion fits in GNSS, aerospace, and software

On this page the work runs entirely in your browser; through the API each successful lookup costs $0.002, failed validation is not charged, and nothing is stored after the response returns. That split—free interactive exploration and a priced, identical API—matches the rest of the KIT tier-A catalog and lets you move from a classroom demo to an automated pipeline without changing the mathematical result.