Web Mercator meters per pixel
Find how many metres of ground one pixel covers on a Web Mercator map: at zoom 12 on the equator it is 38.2185141426 m, halving with each zoom step and shrinking toward the poles. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Zoom
- 12
- Latitude in decimal degrees
- 0
- Meters per pixel
- 38.2185141426
- Meters per tile
- 9,783.9396205
- Circumference at latitude m
- 40,075,016.6856
- Equatorial circumference m
- 40,075,016.6856
Web Mercator ground resolution answers a practical mapping question: at this zoom level and this latitude, how many meters on the ground does one map pixel represent? Tile servers, mobile SDKs, and GIS notebooks all need that number to size buffers, draw scale bars, pick sensible cluster radii, and convert screen distances into geographic distances without round-tripping through a full projection library. The classic formula multiplies the equatorial circumference of the WGS84 sphere used by EPSG:3857 by the cosine of latitude and divides by the number of pixels across the world at that zoom—two hundred fifty-six times two to the power of the zoom level. At the equator and zoom zero you recover the well-known constant about one hundred fifty-six thousand five hundred forty-three meters per pixel; each zoom step halves that value, and higher latitudes shrink it by cos(latitude). Negative zoom and latitude outside the geographic range are rejected with a clear validation error instead of inventing a fake resolution.
How Web Mercator meters per pixel is computed
Start from the equatorial radius used by Web Mercator and almost every commercial XYZ tile stack: R equals six million three hundred seventy-eight thousand one hundred thirty-seven meters. The full equatorial circumference is two pi R. Slippy-map tiles are two hundred fifty-six pixels on a side, and at zoom z the world is covered by two to the z tiles along each axis, so the equator is represented by two hundred fifty-six times two to the z pixels from west to east.
Ground resolution on the equator is therefore circumference divided by that pixel count. Away from the equator, meridians stay the same length in the projection math but parallel circles shrink with the cosine of geodetic latitude, so you multiply by cos(phi) measured in radians. Zoom must be a non-negative integer in a practical slippy range; negative zoom has no meaning in a discrete pyramid and is rejected.
Poles are allowed and correctly drive cosine toward zero so meters per pixel collapses, matching the geometric fact that an east-west pixel covers vanishing ground distance near the poles in this model.
What you send and what you get back
Send two numbers: zoom as a non-negative integer slippy-map level, and latitude as a finite decimal degree value with north positive. Both fields are required. Negative zoom fails with a message that zoom must be non-negative; latitude outside negative ninety to positive ninety fails with an out-of-range message so clients can fix GPS or geocoder glitches instead of guessing.
Classic checks include zoom twelve at the equator for roughly thirty-eight meters per pixel, zoom zero at latitude zero for the full initial resolution constant, and a mid-latitude city zoom such as twelve near fifty-one degrees for a visibly smaller meter-per-pixel value than the equator.
Where meters-per-pixel calculators show up in real work
Product map teams need scale bars and “about N meters across this view” copy that stay honest as users pan north or south; hard-coding an equatorial constant at high latitudes misleads drivers and field workers. Geospatial data pipelines convert pixel tolerances from computer vision or raster analytics into ground distances before buffering features or deciding whether two detections are the same object.
Mobile offline packs and cluster algorithms choose radii in meters that must map back to tile pixels at a target zoom without importing a heavy projection stack into every worker. Curriculum and interview problems often ask for the OSM resolution formula; a single trusted oracle that returns meters per pixel plus circumference helpers speeds grading and demo setup.
If you later need tile X/Y indices from lat/lon, Bing quadkey decode, great-circle distance, or destination points along a bearing, treat those as separate search intents and landings rather than overloading this ground-resolution page—the SEO intent here is specifically Web Mercator meters per pixel from zoom and latitude.
What you can do with it
Map scale bars and “meters across view” labels
Convert current zoom and map center latitude into meters per pixel so UI scale bars and distance chips stay accurate as users pan toward the poles.
Pixel tolerances to ground buffers
Turn computer-vision or click-radius pixel thresholds into meters for buffering features and deduplicating detections at a chosen tile zoom.
Cluster radii and offline tile packs
Pick cluster and search radii in meters that correspond to a target slippy zoom without shipping a full projection library to every edge worker.
FAQ
What happens if zoom is negative?
Negative zoom is not defined for slippy-map pyramids; zoom must be a non-negative integer (practically 0–30).
What latitude range is accepted?
Latitude must be in the closed interval [-90, 90] degrees. Values outside that range are rejected as out of range. Near the poles, cos(φ) drives meters per pixel toward zero.
Why is the Earth radius 6378137 meters?
That is the WGS84 equatorial radius used by Web Mercator (EPSG:3857). The classic ~156543.0339 m/px constant at zoom 0 on the equator assumes this radius and 256 px tiles.
What does it cost?
The browser tool is free and runs locally.
How much does each zoom level change the result?
Each step up in zoom halves the meters per pixel. On the equator at zoom 0 one pixel covers about 156,543 meters; at zoom 12 it is down to 38.2185141426 meters.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/geo/meters-per-pixel \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"zoom":12,"latitude":0}'const res = await fetch("https://api.kit.forhosting.com/geo/meters-per-pixel", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"zoom": 12,
"latitude": 0
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/geo/meters-per-pixel",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"zoom": 12,
"latitude": 0
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/geo/meters-per-pixel", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"zoom":12,"latitude":0}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"zoom":12,"latitude":0}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/geo/meters-per-pixel", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"zoom": 12,
"latitude": 0
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "geo.meters_per_pixel",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
This capability returns meters per pixel plus helpers such as meters per tile edge and circumference at latitude so you can wire scale UI, snap thresholds, and API payloads from one deterministic parse path.
How Web Mercator meters per pixel is computed
Putting the pieces together yields meters_per_pixel equals cos(phi) times two pi R divided by tile_size times two to the z—or equivalently the published initial resolution constant times cos(phi) over two to the z. The result is deterministic floating-point arithmetic: no random seeds, no wall-clock timestamps, no network calls, and no model drift, so identical zoom and latitude always produce identical JSON. Latitude must lie in the closed geographic interval from negative ninety to positive ninety degrees; values outside that range are not valid Earth latitudes and fail with invalid_input.
What you send and what you get back
Missing fields, non-numeric strings, NaN, and Infinity fail with invalid_input and are not charged. On success the response echoes cleaned zoom and latitude, the primary meters_per_pixel value, meters_per_tile as that value times two hundred fifty-six, circumference_at_latitude_m for scale-bar math, equatorial_circumference_m for reference, initial_resolution_m_per_px at zoom zero on the equator, earth_radius_m, tile_size_px, a method label, and a compact formula string. Pricing for successful API calls is the published base of $0.002 per item; validation failures do not consume prepaid balance.
Where meters-per-pixel calculators show up in real work
Because this capability is a pure parse engine, API pricing is the published base of $0.002 per successful item and failed validation does not consume balance.
Technical questions
What formula does this meters-per-pixel calculator use?
Web Mercator ground resolution: mpp = cos(φ) · 2πR / (tile_size · 2^z) with R = 6378137 m and tile_size = 256, matching EPSG:3857 / OSM / Mapbox conventions.