Longitude Regex
Validates a decimal longitude value within the real-world range of -180 to 180 degrees, with an optional fractional component of any precision.
Regex Pattern
^-?(180(\.0+)?|1[0-7][0-9](\.[0-9]+)?|[1-9]?[0-9](\.[0-9]+)?)$Pattern Breakdown
Hover over a token to see what it does.
| Token | Meaning |
|---|---|
| ^ | Anchors the match to the start of the string |
| -? | Optional leading minus sign for western-hemisphere longitudes |
| 180(\.0+)? | The exact boundary value 180, optionally followed by a decimal point and one or more zeros (e.g. 180.0) |
| 1[0-7][0-9](\.[0-9]+)? | Any three-digit integer from 100 to 179, optionally followed by fractional digits |
| [1-9]?[0-9](\.[0-9]+)? | Any integer from 0 to 99, optionally followed by fractional digits |
| $ | Anchors the match to the end of the string |
Detailed Explanation
What it does
This pattern validates that a string represents a longitude value between -180 and 180 degrees inclusive, with any number of decimal places. It special-cases the exact 180 boundary, allows three-digit values from 100-179, and allows one- or two-digit values from 0-99, each with optional decimals.
Why it works
Longitude ranges over a full 360-degree circle split into +/-180 degrees, so the integer part can be one, two, or three digits. The pattern models this with three alternatives ordered so the most specific cases are checked first: an exact-180 branch that only allows trailing zeros in the decimal part (since 180.5 would exceed the range), a 100-179 branch built from 1[0-7][0-9], and a 0-99 branch built from [1-9]?[0-9]. The optional leading '-' covers the Western Hemisphere, and anchoring with ^ and $ ensures the full string is validated rather than a substring.
Common use cases
- Validating longitude fields in map-based forms before geocoding or storing coordinates
- Filtering CSV or API payloads of geographic data for out-of-range longitude values
- Client-side validation for GPS coordinate entry in logistics or travel apps
- Data-quality checks before plotting points on a map to catch malformed or out-of-range values
Edge cases
- The exact antimeridian values '180' and '-180' are valid, but '180.5' and '-181' are correctly rejected
- '180.0' and similar trailing-zero decimals at the boundary are accepted since they still represent exactly 180 degrees
- Three-digit values like '179.999' just under the boundary are correctly accepted by the 100-179 branch
- A bare integer like '0' or '74' is valid since the fractional part is optional
Limitations
- Does not validate an accompanying latitude value; pair with a latitude or combined lat/lng pattern for full coordinate validation
- Does not reject leading zeros beyond what the character classes already exclude (e.g. '045' is rejected since [1-9]?[0-9] disallows an extra leading zero digit)
- Treats '180.1' as invalid even though some lenient systems might normalize longitudes past the antimeridian; strict range checking is by design here
- Does not perform any conversion from DMS (degrees/minutes/seconds) notation, only validates plain decimal degrees
Interactive Tester
Edit the pattern or text below — matching runs live in your browser.
Test Cases
Editable — add your own inputs to see if they pass.
| Input | Expected | Result | |
|---|---|---|---|
| Pass | |||
| Pass | |||
| Pass | |||
| Pass | |||
| Pass | |||
| Pass | |||
| Pass | |||
| Pass | |||
| Pass | |||
| Pass |
Language Variants
Production-ready examples in 12 languages.
const longitudeRegex = /^-?(180(\.0+)?|1[0-7][0-9](\.[0-9]+)?|[1-9]?[0-9](\.[0-9]+)?)$/;
console.log(longitudeRegex.test('-74.0060')); // trueCommon Mistakes
Reusing the latitude pattern's 90-degree bound for longitude, which incorrectly rejects valid values like '120' or '-150'
Fix: Use a dedicated longitude pattern with a 180-degree bound and its own three-digit branch for 100-179
Allowing '180.5' or other non-zero decimals at the 180 boundary, which is outside the valid longitude range
Fix: Special-case the 180 boundary to only allow trailing zeros after the decimal point, as in 180(\.0+)?
Ordering the alternation branches so a shorter, more general branch matches before the exact-180 branch is tried, causing subtle partial matches in engines without full-string anchors
Fix: Keep the exact boundary alternative first (or rely on ^...$ anchors so the full string must match) so an ambiguous input can't slip through
Performance Notes
- The three-way alternation is small and mutually exclusive by leading digit, so backtracking cost stays minimal even on non-matching input
- Anchoring with ^ and $ allows the engine to fail fast on out-of-range or non-numeric strings
- For bulk validation of geographic datasets, precompile the regex once and consider pairing it with a numeric range check for defense in depth
Browser Compatibility
| Engine | Supported | Notes |
|---|---|---|
| Chrome | Yes | — |
| Firefox | Yes | — |
| Safari | Yes | — |
| Edge | Yes | — |
| Node.js | Yes | — |