What Is the Hosts File, and How Does It Override DNS?

Before DNS existed, every computer on the ARPANET resolved names using a single text file called HOSTS.TXT, downloaded periodically from a central server at Stanford Research Institute. DNS replaced that system in the 1980s, but the idea never fully went away. Every modern operating system still ships with a hosts file, and by default it wins over DNS. Add one line to it and you can make example.com point anywhere you like, on your machine only.

That makes the hosts file one of the most useful tools for web developers and site owners, and also one of the most common causes of "it works for everyone except me." This article explains what the hosts file is, where it lives on each OS, how it takes priority over DNS, how to edit it safely, and the practical jobs it's good for, along with its limits. If you need a refresher on how a normal lookup works when the hosts file isn't involved, see the role of a DNS resolver.

What Is the Hosts File?

The hosts file is a plain-text file that maps hostnames to IP addresses. When a program on your computer asks the operating system to resolve a name, the OS checks this file before (or instead of) sending a DNS query. If it finds a match, it returns that address immediately and no DNS query is ever sent.

A typical hosts file looks like this:

# Static table lookup for hostnames
127.0.0.1       localhost
::1             localhost

# Local development
127.0.0.1       myapp.test
127.0.0.1       api.myapp.test

# Preview the new server before switching DNS
203.0.113.10    example.com www.example.com

The format is simple:

1. An IP address, IPv4 or IPv6, at the start of the line.
2. One or more hostnames, separated by spaces or tabs. The first is the canonical name; any others are aliases.
3. Comments start with # and run to the end of the line.

There are no record types, no TTLs, and no zones. Each line is a direct, static name-to-address mapping.

Where the Hosts File Lives

OS	Path
Windows 10 / 11	C:\Windows\System32\drivers\etc\hosts
macOS	/etc/hosts (a symlink to /private/etc/hosts)
Linux	/etc/hosts
Android	/system/etc/hosts (read-only without root)
iOS / iPadOS	Not user-editable

On Windows, the file has no extension. If you save it from Notepad as hosts.txt, Windows will ignore it.

How the Hosts File Overrides DNS

The override happens inside the operating system's name resolution layer, before any packet leaves your machine.

On Linux

The order is defined in /etc/nsswitch.conf. The relevant line usually looks like this:

hosts: files mdns4_minimal [NOTFOUND=return] dns

files means /etc/hosts, and it's listed first. So when a program calls getaddrinfo(), glibc consults /etc/hosts, then multicast DNS, and only then sends a real DNS query. If you moved dns before files, DNS would win instead, although almost no one does that.

On systems running systemd-resolved, the resolver also reads /etc/hosts and serves those entries to clients that talk to it directly, so the override still applies.

On macOS

macOS uses its own resolver framework through mDNSResponder and Directory Services, but the behavior is the same: entries in /etc/hosts are returned ahead of DNS.

On Windows

The DNS Client service loads the hosts file into its cache at startup and whenever the file changes. You can see the entries with:

ipconfig /displaydns

Hosts file entries appear in the cache alongside DNS answers and survive a cache flush, because Windows reloads them immediately.

The precedence in practice

Because the hosts file is checked first, it beats everything DNS-related: your router's resolver, your ISP, public DNS, and the authoritative zone. A correct, fully propagated DNS change still has no effect on a machine with a conflicting hosts entry.

Why dig and nslookup Ignore the Hosts File

This catches people constantly. Tools like dig, nslookup, host, and kdig are DNS clients. They build DNS packets and send them straight to a DNS server, bypassing the operating system's resolver entirely. They never read the hosts file.

So if dig example.com returns the new IP but your browser goes to the old one, a hosts entry is a prime suspect. To see what the OS resolver returns (hosts file included), use these instead:

# Linux: queries via nsswitch, so /etc/hosts is honored
getent hosts example.com

# macOS: queries the system resolver
dscacheutil -q host -a name example.com

# Windows: Resolve-DnsName honors the hosts file by default
Resolve-DnsName example.com

# Add -DnsOnly to skip the hosts file and query DNS directly
Resolve-DnsName example.com -DnsOnly

Running Resolve-DnsName with and without -DnsOnly is a quick, definitive test on Windows: if the answers differ, the hosts file is overriding DNS. ping example.com also goes through the OS resolver on every platform and shows the IP it resolved, which makes it a handy cross-platform check.

How to Edit the Hosts File

Editing requires administrator or root privileges on every desktop OS.

Windows

1. Open the Start menu and search for Notepad.
2. Right-click it and choose Run as administrator.
3. Use File, Open, navigate to C:\Windows\System32\drivers\etc\, and change the file filter to All Files so hosts appears.
4. Add your lines and save.

Or append an entry from an elevated PowerShell window:

Add-Content -Path "$env:windir\System32\drivers\etc\hosts" -Value "203.0.113.10`texample.com www.example.com"

The backtick-t inserts a tab between the address and the names. Some antivirus and endpoint protection tools block or revert hosts file changes; if your edits vanish, check their settings.

macOS and Linux

sudo nano /etc/hosts

Add your lines, then save with Ctrl+O and exit with Ctrl+X. To append a line without opening an editor:

echo "203.0.113.10  example.com www.example.com" | sudo tee -a /etc/hosts

Using sudo tee -a is necessary because a plain sudo echo ... >> /etc/hosts fails: the redirection runs in your unprivileged shell, not as root.

After editing

Changes are usually picked up immediately, but cached answers from before the edit may linger. Flush the OS cache to be sure, and restart or clear the browser's own cache. The commands for each platform are in how to flush the DNS cache.

Practical Uses for the Hosts File

1. Previewing a site before switching DNS

This is the most valuable use for site owners. When you migrate a site to a new host, point the domain at the new server on your machine only:

203.0.113.10    example.com www.example.com

You can now browse the real domain against the new server, with correct Host headers and TLS SNI, and test everything before changing public DNS. Remove the line once DNS is switched over. This is a standard step in a zero-downtime DNS migration.

2. Local development domains

Map friendly names to your local machine:

127.0.0.1    myapp.test
127.0.0.1    admin.myapp.test
::1          myapp.test

Use the reserved .test TLD for this, since it will never be delegated in public DNS. Avoid .dev (a real TLD that browsers force onto HTTPS) and .local (reserved for multicast DNS, which can cause slow lookups). Names ending in .localhost already resolve to the loopback address in most modern browsers and systems without any hosts entry.

3. Blocking domains

Pointing a hostname at an unroutable address effectively blocks it:

0.0.0.0    ads.example.net
0.0.0.0    tracker.example.org

0.0.0.0 fails faster than 127.0.0.1 because nothing tries to connect to a local web server. Community-maintained block lists use exactly this format. For a whole network, though, a DNS-level blocker scales much better; see how to block ads across your network with Pi-hole.

4. Working around a DNS outage

If your DNS provider is down but your servers aren't, a temporary hosts entry lets you, or your team, reach critical systems by name until DNS is restored.

5. Testing in staging with production URLs

Some applications hard-code absolute URLs. Pointing the production hostname at a staging server on a test machine lets you exercise the app unmodified.

Limitations of the Hosts File

The hosts file is deliberately primitive, and that shapes what it can and can't do:

1. No wildcards. *.example.com is not valid. Every subdomain needs its own line. For wildcard local development, run a small local resolver such as dnsmasq with address=/myapp.test/127.0.0.1.
2. No ports. It maps names to IPs only. example.com:8080 won't work; use a reverse proxy for port mapping.
3. No other record types. There are no MX, TXT, CNAME, or SRV entries. Email delivery, SPF checks, and service discovery are unaffected.
4. Local to one machine. Every developer, phone, and test device needs its own edit. For anything shared, use a real DNS zone or split-horizon DNS.
5. Applications can bypass it. Programs that bring their own DNS client, including tools like dig and some browsers in strict DNS-over-HTTPS modes, may not consult the file. Most browsers still honor the hosts file even with secure DNS enabled, but behavior varies by browser and setting.
6. Containers have their own. Docker containers get a separate /etc/hosts. Use --add-host or the extra_hosts key in Compose to add entries inside a container:

services:
  web:
    image: nginx:stable
    extra_hosts:
      - "api.example.com:203.0.113.20"

This writes the mapping into the container's own /etc/hosts, leaving the host machine's file untouched.

Security: Hosts File Hijacking

Because the hosts file silently overrides DNS, malware has long targeted it. An attacker who can write to the file can redirect your bank's domain to a phishing server, or block security-update domains so your antivirus can't update. It's a local form of the redirection described in DNS hijacking.

To protect yourself:

• Keep the file owned by root or Administrators and not writable by regular users (the default on every modern OS).
• Review it occasionally. On a typical machine it should contain only localhost entries plus anything you added deliberately.
• Watch for unexpected entries for banking, email, or software-update domains; these are a classic sign of compromise.
• On managed fleets, monitor the file for changes with your endpoint security tools.

A quick way to list only the non-comment, non-localhost entries:

grep -vE '^\s*(#|$)' /etc/hosts | grep -vw localhost

This filters out comments, blank lines, and localhost mappings, leaving only the overrides you should be able to explain.

---

Hosts File FAQ

Conclusion

The hosts file is the oldest name-resolution mechanism still in daily use, and its simplicity is the point. One line maps a name to an address on your machine, ahead of every DNS server in the world. That makes it ideal for previewing a site on a new server, giving local projects memorable names, or blocking a handful of domains, and it's equally good at causing confusing, machine-specific problems when an entry is forgotten.

Use it deliberately: add a comment explaining each override, remove entries when you're done with them, and remember that dig and nslookup won't see them. When behavior differs between your machine and everyone else's, check the hosts file before anything else.

For deeper reading on the hosts file and how systems use it, see these references:

1. RFC 952: DoD Internet Host Table Specification — the original specification for the host table format that the hosts file descends from.
2. RFC 6761: Special-Use Domain Names — reserves .test, .localhost, and other names suitable for local use.
3. Microsoft Learn: Resolve-DnsName — documents the -DnsOnly switch and other resolution options.
4. Docker Docs: Compose file reference — covers extra_hosts for adding hosts entries inside containers.