How to Clear the DNS Cache in Chrome, Firefox, and Edge?

You flushed your operating system's DNS cache, dig shows the new IP address, and yet the browser tab still loads the old server. That's because modern browsers don't rely entirely on the operating system for DNS. Chrome, Edge, and Firefox each keep their own host cache inside the browser process, and they also hold open connections to servers they've already reached. Until you clear both, the browser can keep talking to the old IP.

This guide shows you exactly how to clear the browser-level DNS cache in Chrome, Firefox, and Edge (plus Brave, Opera, and Safari), how to flush the socket pools that keep old connections alive, and how to tell whether the browser or something else is holding the stale answer. For the operating system layer underneath, use the separate guide on how to flush the DNS cache on Windows, macOS, and Linux.

Why Browsers Have Their Own DNS Cache

Page loads involve dozens or hundreds of hostnames: the site itself, CDNs, analytics, fonts, APIs. Even a fast OS lookup costs a system call and some milliseconds, so browsers keep a small in-memory cache of recent answers to skip that work entirely. They also resolve names ahead of time based on links and hints in the page, a technique covered in what DNS prefetching is.

There's a second reason. When secure DNS is enabled (DNS over HTTPS), the browser doesn't use the OS resolver at all; it sends queries straight to a DoH provider and caches the answers itself. In that mode, flushing the OS cache has no effect on the browser whatsoever. See what DNS over HTTPS is for how that works.

The browser cache is short-lived. Entries typically last around a minute, often less than the record's real TTL. So in many cases simply waiting briefly, or restarting the browser, clears it. The steps below are for when you want the change to take effect immediately.

Clear the DNS Cache in Google Chrome

Chrome exposes its network internals on a special page.

1. Open a new tab and go to chrome://net-internals/#dns.
2. Click Clear host cache.
3. Go to chrome://net-internals/#sockets.
4. Click Flush socket pools.
5. Reload the site you were testing, ideally with a hard reload (Ctrl+Shift+R on Windows and Linux, Cmd+Shift+R on macOS).

Step 2 empties Chrome's internal host resolver cache. Steps 3 and 4 matter just as much: Chrome keeps idle HTTP/1.1, HTTP/2, and HTTP/3 connections open for reuse. If a connection to the old IP is still alive, Chrome will happily keep using it even with a clean DNS cache. Flushing socket pools closes those connections so the next request starts with a fresh lookup.

The DNS page also includes a hostname lookup box that shows what Chrome's resolver currently returns for a name. It's a quick way to confirm the browser sees the new address without opening a terminal.

Check Chrome's secure DNS setting

Open chrome://settings/security and look for Use secure DNS. If it's on and set to a specific provider, Chrome is resolving names through that provider rather than your OS or router. That matters in two situations:

• If you're testing an internal or split-horizon name that only your local resolver knows about, secure DNS may bypass it. Chrome usually detects managed or enterprise environments and falls back automatically, but not always.
• If the DoH provider still has the old record cached, clearing Chrome's cache won't help until that provider's TTL expires.

Clear the DNS Cache in Microsoft Edge

Edge is built on Chromium, so the process mirrors Chrome's with a different URL scheme.

1. Go to edge://net-internals/#dns.
2. Click Clear host cache.
3. Go to edge://net-internals/#sockets.
4. Click Flush socket pools.
5. Reload the page.

Edge's secure DNS option lives under edge://settings/privacy in the Security section, labeled Use secure DNS to specify how to look up the network address for websites. As with Chrome, check this when the browser disagrees with command-line tools.

Clear the DNS Cache in Mozilla Firefox

Firefox has its own network stack and a different diagnostics page.

1. Open a new tab and go to about:networking#dns.
2. Click Clear DNS Cache.
3. Reload the site.

The DNS tab lists every hostname Firefox has cached, the address family, whether the entry came through TRR (Firefox's name for DNS over HTTPS), the resolved addresses, and when each entry expires. Checking this table before you clear is a fast way to confirm Firefox really is holding the old IP.

Firefox also keeps persistent connections. There's no "flush sockets" button, but the Sockets and HTTP tabs on about:networking show active connections. If a stale connection persists after clearing the DNS cache, closing every tab for that site, or restarting Firefox, closes it.

Firefox DNS preferences worth knowing

Firefox exposes its cache behavior in about:config. Two preferences are relevant:

network.dnsCacheExpiration      # how long, in seconds, entries are kept
network.dnsCacheEntries         # maximum number of cached hostnames

During development you can temporarily set network.dnsCacheExpiration to 0 to stop Firefox from caching DNS at all, then reset it when you're done with the Reset arrow next to the preference. Don't leave caching disabled for normal browsing; it makes every page load slower.

Firefox's DNS over HTTPS setting is under Settings, Privacy & Security, DNS over HTTPS. The network.trr.mode preference in about:config shows the current mode: 0 or 5 mean off, 2 means DoH with fallback to the OS resolver, and 3 means DoH only.

Brave, Opera, Vivaldi, and Other Chromium Browsers

Every Chromium-based browser keeps the same internals page under its own scheme, or simply accepts chrome://:

Browser	DNS cache page	Socket pools page
Chrome	chrome://net-internals/#dns	chrome://net-internals/#sockets
Edge	edge://net-internals/#dns	edge://net-internals/#sockets
Brave	brave://net-internals/#dns	brave://net-internals/#sockets
Opera	opera://net-internals/#dns	opera://net-internals/#sockets
Vivaldi	vivaldi://net-internals/#dns	vivaldi://net-internals/#sockets
Firefox	about:networking#dns	No equivalent button

The buttons and their behavior are the same across all of them.

What About Safari?

Safari doesn't maintain a separate, user-clearable DNS cache. It resolves names through macOS (or iOS) system services, so the correct step is to flush the OS cache. The Empty Caches option in Safari's Develop menu clears cached web content, not DNS. After flushing the OS cache, quit and reopen Safari to drop any persistent connections.

Clearing Browsing Data Is Not the Same Thing

A common mistake is opening the browser's "Clear browsing data" dialog and wiping cookies and cached images in the hope of fixing a DNS issue. That dialog clears:

• HTTP cache (cached files such as images, scripts, and pages)
• Cookies and site data
• History

It does not reliably clear the host resolver cache or close open connections. Worse, it logs you out of everything. If the problem is that the browser is reaching the wrong server, use the net-internals or about:networking pages instead.

There are, however, a few browser caches that can mimic DNS problems:

1. Cached redirects. A 301 Moved Permanently is cached by the browser, sometimes for a long time. If a domain used to redirect elsewhere, you'll keep landing at the old destination even with perfect DNS. Clearing cached images and files, or testing in a private window, fixes this.
2. HSTS. If a site previously sent an HSTS header, the browser forces HTTPS for it. Moving that domain to a server without a valid certificate will produce certificate errors that look like a hosting problem.
3. Service workers. A service worker can serve a cached version of a site without contacting the network at all. Check DevTools, then Application, then Service Workers, and unregister it.

How to Tell Which Layer Is Stale

When the browser shows something different from what you expect, compare three views of the same name.

First, what the authoritative DNS says, using a direct query to a public resolver:

dig @1.1.1.1 www.example.com A +short

Second, what the operating system returns:

# Linux
getent hosts www.example.com

# macOS
dscacheutil -q host -a name www.example.com

# Windows
Resolve-DnsName www.example.com -Type A

Third, what the browser itself is using. Open DevTools (F12), switch to the Network tab, reload, select the main document request, and look for the Remote Address field in the Headers pane. That's the IP the browser actually connected to.

Then interpret:

• Browser differs from the OS: the browser's host cache or an open connection is stale. Clear the host cache and flush socket pools, or check whether secure DNS is enabled.
• OS differs from the public resolver: the OS cache or the hosts file is stale. Flush the OS cache and check the hosts file.
• All three agree on the old IP: your resolver or the authoritative zone still has the old record. See how to check if DNS changes have propagated.

Testing Without Clearing Anything

When you just want to see the new server once, a few tricks avoid touching caches:

• Use a private or incognito window. It starts with a separate connection pool, though it may still share the host cache in some browsers.
• Use a different browser. Each browser has its own cache, so a browser you haven't used for this site starts clean.
• Pin the IP with curl. This bypasses DNS entirely and proves the new server responds correctly:

curl -sI --resolve www.example.com:443:203.0.113.10 https://www.example.com/

The --resolve option tells curl to use 203.0.113.10 for www.example.com on port 443 without performing any lookup, while still sending the correct Host header and SNI. If this returns the expected response, the new server is fine and only caching remains.

• Launch Chrome with a host rule. For a one-off test session, Chrome accepts a mapping flag:

google-chrome --user-data-dir=/tmp/chrome-test \
  --host-resolver-rules="MAP www.example.com 203.0.113.10"

This starts an isolated Chrome profile where www.example.com resolves to the given IP. On macOS, launch the binary inside /Applications/Google Chrome.app/Contents/MacOS/ with the same flags.

---

Browser DNS Cache FAQ

Conclusion

Browsers sit on top of the operating system's resolver and add their own caching layer, plus a pool of reusable connections. In Chrome, Edge, Brave, and other Chromium browsers, clear the host cache at net-internals/#dns and flush socket pools at net-internals/#sockets. In Firefox, use the Clear DNS Cache button at about:networking#dns. Safari has no separate cache, so flushing macOS is enough.

When a site still looks wrong, don't keep clearing everything at random. Compare what DevTools says the browser connected to with what the OS and a public resolver return. That comparison tells you which layer is stale in under a minute, and whether the fix is a browser button, an OS flush, a hosts file entry, or simply waiting for the TTL to expire.

These references document the browser and networking features used above:

1. Chromium Project: Chromium Documentation — design notes on Chromium's network stack, including host resolution and socket pools.
2. Mozilla Support: Firefox DNS over HTTPS — explains Firefox's DoH settings and modes.
3. Google Chrome Help: Chrome Help Center — official help for Chrome settings, including secure DNS.
4. MDN Web Docs: Strict-Transport-Security — how HSTS causes browsers to remember HTTPS-only behavior.
5. curl documentation: curl man page — reference for --resolve and other options useful for bypassing DNS during tests.