chain
#
HTTP 403 Forbidden
⌃⏎ run · clear · / focus input
Meaning
send output to
no matches
Result appears here as you type
runs in your browser · nothing uploaded
// about this tool

HTTP 403 Forbidden Online

Updated 2026-07-26

HTTP 403 Forbidden means the server knows exactly who you are — you're authenticated — but has decided you're not allowed to access this specific resource. It's a permissions problem, not a login problem, which is the key thing that separates it from 401 Unauthorized.

If you're seeing a 403 despite being logged in with the right account, check the specific permission scope required (a role, an API token's granted scopes, resource ownership) rather than the login state itself — and rule out a WAF, CDN, or IP allowlist blocking the request before it even reaches your application. For every other status code at once, use the full HTTP Status Codes reference.

// how to use

  1. 1 The code is already looked up below — 403 is pre-filled.
  2. 2 Type any other status code to look that one up instead.
  3. 3 Copy the result, or use the full HTTP Status Codes reference for every code at once.

// examples

The code itself
Input
403
Output
403 Forbidden — Client Error (4xx). The server understood the request but refuses to authorize it.
The code it's often confused with
Input
401
Output
401 Unauthorized — you haven't authenticated at all, or your credentials are invalid.

// common uses

Debugging why an authenticated request is still being blocked Distinguishing a permissions problem (403) from a login problem (401) Investigating a WAF/CDN rule that's blocking legitimate traffic Checking what a status code in server logs actually means

// faq

Is anything uploaded to a server?
No. The lookup runs entirely in your browser from a built-in table, so nothing you type leaves your machine.
What's the difference between 403 and 401?
401 means the server doesn't know who you are yet. 403 means it does — you're authenticated — but your account or role isn't allowed to access this specific resource. Logging in again won't fix a 403.
I'm logged in as an admin but still get 403 — why?
The permission check is usually scoped narrower than "logged in" — a specific role, an API scope your token wasn't granted, an IP allowlist, or a resource-level ownership check that fails even for admins on someone else's data.
Can a web server firewall or CDN return 403 too?
Yes — a misconfigured WAF rule, a blocked IP range, or a bot-protection service can all return 403 before the request even reaches your application, which is why the same request can 403 from one network and succeed from another.
Should a 403 ever be shown as a 404 instead?
Sometimes deliberately — some APIs return 404 instead of 403 for resources a user shouldn't even know exist, to avoid confirming the resource is there. It's a security-through-obscurity trade-off, not a bug.

Use this via API

Get a free API key →
curl -X POST https://thesnaptools.com/api/v1/tools/http-403 \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"text":"403"}'
Esc
↑↓ navigate open Esc close