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 | — |
Work with this pattern
Take this expression further — test it against your own data, adapt it in the builder, or read up on the syntax behind it.
Regex Tester
Test a regular expression against sample text and see every match highlighted live.
Regex Generator
Build a pattern by clicking blocks — no syntax memorisation required.
Regular Expressions Guide
What regex is, how the syntax works, and the mistakes that trip people up.
Regex Cheat Sheet
Every token, quantifier, and assertion on one printable page.
Python Regex Guide
The re module end to end — search, match, findall, groups, and substitution.
Regex Pattern Library
100+ ready-to-use patterns for email, URLs, dates, IPs, and more.