Google Maps API Key Tester

Before you paste a live API key

There is a twist here that is worth reading twice, because it cuts both ways. A properly restricted key will probably fail on this page — see the section below on why. That is the restriction doing its job. It also means the safest keys to test here are ones that are not yet restricted, which are exactly the keys you should be most careful with.

Google Maps Platform changes over time; endpoints, parameters and status values are all subject to change. This page is an independent guide, not documentation. Check the official Google Maps Platform documentation for authoritative details.

Why a restricted key fails here (and why that is correct)

This deserves its own section because it produces the single most confusing result on this page: a key that demonstrably works on your own site returns REQUEST_DENIED when you test it here. Nothing is broken. The explanation is that the request is made by our server, not by your browser.

An HTTP referrer restriction tells Google to accept the key only when the request carries a Referer header matching a domain you listed. Requests relayed through our proxy do not carry your site's referrer, so the restriction is not satisfied and Google refuses. An IP address restriction tells Google to accept the key only from listed addresses. Requests here originate from our server's IP, which is not on your list, so again Google refuses.

Both refusals are the security control working exactly as designed. What you have learned is genuinely useful — the restriction is active and effective — even though it is not what you were trying to find out. To test a restricted key end to end, exercise it from the environment it is restricted to. To test a key's basic validity here, use an unrestricted or temporarily broadened key, and restrict it again afterwards. Do not leave a key unrestricted because a test was easier that way.

How Maps web services take the key

Google's classic Maps web services — geocoding, directions, distance matrix, elevation, time zone and friends — share a consistent pattern. They live under https://maps.googleapis.com/maps/api/, take a service name and a response format in the path, and read parameters from the query string. The API key is just another query parameter, named key. There is no Authorization header, which is why the Auth tab above is left on "No authentication".

The tester is prefilled with a geocoding request: an address parameter and a key parameter waiting for your key. Geocoding makes a good validity probe because the request is trivial, the address is a well-known public one, and a successful response is unmistakable. Swap in your key, press Send, and read the JSON.

Newer Google APIs do not all follow this pattern. Some accept the key in an X-Goog-Api-Key request header and expect a JSON body rather than query parameters. If you are testing a newer service, check its own documentation for how it wants the key, and use the Headers tab here rather than Params. The HTTP headers guide covers the general mechanics.

Reading the response: status beats the status code

Here is the trap. Google usually returns HTTP 200 even when it rejects your key. The status pill above will show a green 200 and the request will look successful, while the body says otherwise. The authoritative answer is the status field inside the JSON.

A working key produces "status": "OK" and a populated results array with the geocoded address, its formatted form and coordinates. A rejected key produces "status": "REQUEST_DENIED" together with an error_message field, and that message is the most valuable string on the page — Google usually states the actual reason, whether the key is invalid, the specific API is not enabled for the project, billing is not configured, or a restriction blocked the request. Read it literally before theorising.

Other status values you will meet: ZERO_RESULTS means the request was accepted and understood but matched nothing — your key is fine, your address is not. INVALID_REQUEST means a required parameter is missing or malformed, commonly a typo in a parameter name. OVER_QUERY_LIMIT means you have exceeded a quota or your project has a billing problem. Only the first of those is about the key itself.

Because the meaningful content is nested a few levels down, the highlighted JSON above helps; for deeper inspection, the JSON formatter runs locally in your browser.

Creating and restricting a key

Keys are created in the Google Cloud console under a project's credentials section. Three things have to be true before a key will work, and missing any one of them produces a REQUEST_DENIED that looks identical from outside: the key must exist, the specific API you are calling must be enabled for that project, and the project must have billing configured. The "API not enabled" case is by far the most common surprise — a brand-new key is not automatically permitted to call every Google service.

Once the key works, restrict it. Set an application restriction — referrers for keys used from a browser, IP addresses for keys used from a server — and an API restriction listing only the services the key legitimately needs. This page deliberately quotes no quota figures or prices, because those change and a stale number is worse than none; the console shows your project's current position.

When you do get a real error status

Although Google prefers the in-body status field, genuine HTTP errors do occur, especially on newer APIs that behave more conventionally. A 401 Unauthorized or a 403 Forbidden from a Google endpoint points at credentials or permissions: a missing key, a key the project does not permit for this API, or a restriction refusing the caller. A 429 Too Many Requests means you are exceeding a rate limit or quota — back off, honour any Retry-After header, and check your project's quota page rather than retrying in a loop.

If you are working with Google's OAuth flows rather than plain API keys, you will encounter ID tokens that really are JSON Web Tokens; the JWT decoder will show their claims and expiry without transmitting them anywhere. For endpoints that push data to you rather than the other way round, see the webhook tester, and for anything without Google-specific defaults use the REST API tester.

Test another provider's API

Frequently asked questions