How to Edit the Host File on Windows, Mac and Linux (2026)

The hosts file (sometimes called the "host file") is a plain text file on your computer that maps domain names to IP addresses. Editing it lets you point custom domains to local servers, test staging sites, or block unwanted domains — all before your browser ever reaches the internet.

Quick answer — how to edit the host file in five steps:

1. Locate the file — Windows: C:\Windows\System32\drivers\etc\hosts · macOS/Linux: /etc/hosts 2. Open with admin rights — Windows: Notepad as administrator · Mac/Linux: sudo nano /etc/hosts 3. Add a line — Format: 127.0.0.1 mysite.test 4. Save — Confirm you have write permission (no "access denied" error) 5. Flush DNS cache — Windows: ipconfig /flushdns · macOS: sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder · Linux: sudo systemd-resolve --flush-caches

The sections below cover each platform in detail, plus syntax rules, safety, and troubleshooting.

Video walkthrough (Windows 11)

Prefer a visual guide? Watch a step-by-step walkthrough of editing the hosts file on Windows 11, then return here for Mac and Linux steps.

<!-- Replace VIDEO_ID with your YouTube upload when published --> How to edit the hosts file on Windows 11 (video)

Edit the host file on Windows

On Windows 10 and Windows 11, the hosts file lives at:

C:\Windows\System32\drivers\etc\hosts

There is no file extension — the file is literally named hosts.

Method: Notepad as administrator

This is the most reliable method on Windows:

1. Press the Windows key, type Notepad 2. Right-click Notepad → Run as administrator 3. Click Yes on the UAC prompt 4. In Notepad: File → Open 5. Navigate to C:\Windows\System32\drivers\etc 6. Change the file type dropdown from "Text Documents (*.txt)" to **All Files (*.*) 7. Select hosts and click Open** 8. Add your entry at the bottom:

127.0.0.1    myproject.test
127.0.0.1    api.myproject.test

9. Press Ctrl+S to save 10. Open Command Prompt as administrator and run:

ipconfig /flushdns

Common Windows errors

"Access is denied" when saving You opened Notepad without administrator privileges. Close it and restart with "Run as administrator."

Cannot find the hosts file in Open dialog Change the file type filter to "All Files (*.*)" — the hosts file has no extension and is hidden by the default filter.

Changes saved but browser still shows old site Run ipconfig /flushdns, then clear your browser DNS cache. In Chrome: chrome://net-internals/#dns → Clear host cache.

For Windows 10-specific steps see Edit hosts file on Windows 10. For Windows 11 (including PowerShell method) see Edit hosts file on Windows 11.

Edit the host file on macOS

On Mac, the hosts file is at /etc/hosts and requires sudo (administrator password).

Terminal method

sudo nano /etc/hosts

Add your entries, then save with Ctrl+O, Enter, Ctrl+X.

Flush DNS cache (required on macOS):

sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

Verify with:

ping myproject.test

For the full Mac walkthrough — including GUI alternatives and troubleshooting — see Edit hosts file on Mac.

Edit the host file on Linux

On most Linux distributions, the hosts file is also at /etc/hosts.

sudo nano /etc/hosts

Or with vim:

sudo vim /etc/hosts

Add entries, save, then flush DNS:

# systemd-resolved (Ubuntu, Fedora, Debian)
sudo systemd-resolve --flush-caches

# Or on older systems
sudo /etc/init.d/nscd restart

For distribution-specific details see Edit hosts file on Linux and Edit hosts file on Ubuntu.

Host file syntax

Every hosts file entry follows one simple rule:

IP_address    domain_name    [optional_aliases]

Examples:

# Local development
127.0.0.1       app.myproject.test
127.0.0.1       api.myproject.test

# IPv6 localhost
::1             app.myproject.test

# Temporary staging override
203.0.113.50    www.example.com

# Block a domain
0.0.0.0         ads.example.com

Rules to remember:

• One IP per line, followed by one or more domain names separated by spaces or tabs
• Lines starting with # are comments
• No wildcards (*.example.com is not supported)
• The first matching entry wins if duplicates exist
• Mix IPv4 and IPv6 on separate lines

For a complete syntax reference see Hosts file syntax and format guide and Complete hosts file guide.

Is it safe to edit the hosts file?

Yes — editing the hosts file is safe for normal use cases like local development, staging tests, and blocking ads. The file is plain text; you can always revert changes by deleting lines or restoring a backup.

Safe practices:

• Back up the file before bulk edits: sudo cp /etc/hosts /etc/hosts.backup
• Use comments to document why each entry exists
• Remove temporary entries (staging overrides) when done
• Avoid redirecting critical domains unless you understand the impact

When to be cautious:

• Redirecting banking or login domains (even accidentally)
• Importing untrusted blocklists without review
• Leaving stale staging overrides that break production sites

Read the full safety analysis in Is editing the hosts file safe?

Changes not working?

If your hosts file edit saved successfully but the domain still resolves to the wrong IP, work through this checklist:

1. Did you flush DNS cache? — Required on every platform after every edit 2. Did you save as administrator? — Windows silently fails without admin rights 3. Is the syntax correct? — IP and domain separated by at least one space or tab 4. Is the browser using its own cache? — Chrome and Firefox cache DNS independently 5. Is a VPN or DNS blocker active? — Tools like NextDNS or Pi-hole bypass the hosts file 6. Is systemd-resolved overriding on Ubuntu? — See Ubuntu guide

On Mac, see Hosts file changes not working on Mac.

If you get permission errors, see Edit hosts file as administrator.

Use cases for editing the host file

Local web development Point myapp.test to 127.0.0.1 so your local server responds to a real-looking domain name instead of localhost:3000. Frameworks like Laravel, WordPress, Django, and Next.js all benefit from stable local domain names that match production URL structures. Your cookies, CORS policies, and OAuth redirect URIs behave more realistically when the domain looks like production — even on your laptop.

Staging and migration testing Temporarily point www.client.com to a staging server IP to verify the new site before changing public DNS. This is invaluable during server migrations: QA teams validate the new infrastructure while the public still hits the old server. Always date-stamp these entries and remove them after launch — stale staging overrides are a common source of "works on my machine" confusion weeks later.

Blocking distractions or ads Redirect ad domains to 0.0.0.0 for system-wide blocking. See Block a website with the hosts file. Unlike browser extensions, hosts blocking works in every application on your computer — including desktop Slack, Electron apps, and games with embedded ads.

Corporate or lab environments Map internal hostnames to LAN IP addresses when no internal DNS server is available. Labs, air-gapped networks, and small offices often rely on a shared /etc/hosts snippet distributed to every workstation. Document the canonical list in your internal wiki and version-control the template file — not the live system copy.

QA and multi-environment testing Quality assurance teams frequently override production domains to hit staging or pre-production servers. A single hosts entry lets testers verify checkout flows, authentication, and third-party integrations against non-production backends without waiting for DNS TTL propagation.

Resolution order: where the hosts file fits

Understanding when the hosts file is consulted helps explain both its power and its limits. On all three platforms, the typical resolution order is:

1. Hosts file — static local mappings (your edits) 2. Local DNS cache — may serve stale results until flushed 3. Configured DNS servers — router, ISP, Cloudflare, Google DNS 4. Application-level DNS — browser Secure DNS, VPN DNS, DoH

Because the hosts file is checked first, a local entry always wins over public DNS for that domain — unless an application bypasses the OS resolver entirely. That is why flushing cache matters: step 2 can mask a correct hosts entry until the cache expires or is cleared.

Frequently asked beginner questions

Can I have duplicate entries? Technically yes, but the first matching line wins on most systems. Duplicate lines create confusion during debugging — keep one entry per domain.

Does the hosts file affect Wi-Fi vs Ethernet? No — it is system-wide regardless of network interface. Switching from office Wi-Fi to phone hotspot does not change hosts file behavior.

Will my edits sync to iCloud or OneDrive? No — the hosts file is a local system file outside cloud sync folders. Each machine needs its own entries unless you use a sync tool or shared script.

Do I need to restart after editing? No restart required. Flush DNS cache and restart only the application that cached the old resolution (sometimes required for long-running daemons).

Cross-platform GUI: Locahl

If you edit the hosts file regularly across Windows, Mac, and Linux, a dedicated GUI saves time. Locahl provides a visual interface to manage entries without memorizing file paths or terminal commands — with automatic syntax validation, one-click DNS flush, and backup before every save.

Locahl is available at 4,99 € as a one-time purchase for Windows, macOS, and Linux — with automatic backups, syntax validation, and one-click DNS flush.

Advanced workflows

Once you know how to edit the host file, these guides help with day-to-day workflows:

• Manage multiple hosts configurations — dev, staging, and production profiles
• Docker and the hosts file — map container services locally
• QA teams: test staging before DNS cutover
• Share hosts configurations with your team
• Best hosts file editors — compare GUI tools including Locahl
• Locahl vs Terminal — when a GUI beats sudo nano

Platform-specific guides

---

*Last tested: Windows 11 24H2, macOS 15 (Sequoia), Ubuntu 24.04 LTS — June 2026.*