ngrok skip browser warning: what works and what to avoid

The ngrok skip browser warning search starts after a reviewer clicks a tunnel URL and sees an ngrok-branded warning page instead of your local app.

That page may be acceptable for API testing. It can break the flow in a client review because the reviewer sees tunnel-provider language before they see the product you wanted to show.

This guide explains why the warning exists, which workarounds help, and when a review-focused link avoids the issue.

ngrok skip browser warning: the practical options

You have three common options:

1. Use an API or scripted client that sends the ngrok-skip-browser-warning header.
2. Use an ngrok domain setup that avoids the warning in your plan and configuration.
3. Use a different tunnel tool for reviewer-facing links.

Avoid brittle browser hacks. If your reviewer uses a normal browser, you cannot count on a custom request header unless you control the client code making the request.

For browser-based stakeholder review, the cleanest fix is a link that does not show an interstitial in the first place.

Why the ngrok warning appears

ngrok has had browser warning and abuse-prevention screens for certain free or public tunnel scenarios. The exact presentation can change as ngrok changes products, domains, and abuse controls.

The purpose is understandable: public tunnel URLs can be misused. A warning page helps ngrok reduce abuse and make users aware that a page is served through ngrok.

The product problem is also real. A non-technical reviewer may think your app is unsafe, broken, or asking them to approve something. Even if they click through, the first impression belongs to the tunnel, not your build.

That friction matters when you send a link to a client, designer, investor, or QA reviewer who expects the app to load.

The header workaround

The classic workaround is the ngrok-skip-browser-warning request header:

curl -H "ngrok-skip-browser-warning: true" https://example.ngrok-free.app

This helps for scripts, API clients, test runners, and webhook-style requests where you control the HTTP client. It does not help when you paste a link into Slack and ask a client to open it in Safari or Chrome.

You may find snippets that inject JavaScript, use browser extensions, or rewrite requests. Those create more setup than the tunnel was supposed to remove. They also move the burden to the reviewer, which defeats the point of a review link.

Use the header workaround for machine-to-machine tests. Do not build a client-review process around it.

Use a custom or reserved domain

ngrok’s domain model has changed over time, so check the current docs before you pick a plan. The current ngrok domain docs say every account gets an auto-assigned dev domain, free accounts cannot choose or reserve custom domain names, and bring-your-own custom domains are available on Pay-as-you-go.

A custom domain can improve trust and reduce provider-branded friction. It also adds setup:

1. Own a domain.
2. Add it in the ngrok dashboard.
3. Add the CNAME record with your DNS provider.
4. Start the endpoint with your domain.

ngrok http --url app.example.com 3000

This path makes sense if you use ngrok often, need a stable hostname, or want domain ownership for a team workflow. It is more work than a one-off review window.

Use a review-focused tunnel instead

If the warning page appears in the middle of client review, the issue is not only the warning. The tunnel workflow should be built around the review experience.

For a review link, you need:

• a clean browser path for the reviewer,
• no reviewer account,
• a short expiry window,
• visible viewer joins,
• request and failure signals while the session runs.

wiremaven creates temporary encrypted public links for local dev servers through an outbound WebSocket relay. During beta, there is no account requirement. Links can expire after 15, 30, or 60 minutes.

npx wiremaven-cli 3000 --expires 30m --name client-review

The developer sees live session signals, including viewer connections and failed requests. That gives you more than a URL.

For setup, see the wiremaven docs. For the relay architecture, read how wiremaven works.

When to stay with ngrok

Stay with ngrok when it fits the job.

ngrok remains strong for webhook testing, API callbacks, endpoint traffic inspection, and teams already standardized on its agent and dashboard. Its HTTP docs describe Traffic Inspector, Traffic Policy, automatic TLS handling, and endpoint configuration.

If you use ngrok for a machine client, add the skip header where the client supports it. If you use ngrok for recurring branded links, configure the right domain path for your plan. Switch tools when the reviewer experience matters more than the tunnel ecosystem.

Decision table

FAQ

Can I skip the ngrok browser warning in a normal browser?

Not by pasting a simple URL with a custom header. Browsers do not let you attach arbitrary headers to a clicked link without extra code or extensions.

Does the ngrok-skip-browser-warning header work for APIs?

It can work for clients where you control the request headers, such as curl, scripts, and test clients. Test it against your current ngrok endpoint because provider behavior can change.

Is a custom domain worth it for ngrok?

It is worth it if you use ngrok often and want a stable, trusted hostname. For a single local review, a short-lived review link may be faster.

Start with reviewer friction

If the person opening the link is a client or stakeholder, remove avoidable warning pages from the path.

npx wiremaven-cli 3000 --expires 30m

Related: ngrok custom domain and ngrok alternatives.