The hosts file is the migration world’s best-kept simple trick: a tiny text file on your own computer that lets you preview your migrated site on the new host, under your real domain name, while everyone else still sees the old site. It is the gold-standard way to test before cutover, because it shows you the site exactly as it will behave once live — catching URL and link issues that other preview methods mask. This guide explains what the hosts file is and exactly how to use it to preview a migration safely.

You will learn what the hosts file does, why it is the best preview method, how to find your new server’s IP, how to edit the hosts file on your computer, how to preview and test the migrated site through it, and how to clean up afterward. By the end you will be able to use this simple, powerful technique to test any migration under real-world conditions before you touch DNS.

What the hosts file does

The hosts file is a small text file present on virtually every computer that acts as a local, personal override for DNS. When your computer needs to find the server for a domain, it checks the hosts file first, before asking the internet’s DNS. So if the hosts file contains an entry mapping a domain to a specific server IP, your computer uses that mapping — for that one computer only — regardless of what the public DNS says.

This is exactly what makes it perfect for previewing a migration. By adding an entry that maps your domain to the new host’s server IP, you tell your computer ‘for me, this domain lives at the new host,’ while the public DNS still points everyone else to the old host. The result: you see the migrated site on the new host under your real domain, and the rest of the world continues to see the old site, undisturbed.

So the hosts file is a private, per-computer DNS override, and using it for migration means creating a personal preview of the switched-over state without actually switching anything for anyone else. It is a completely safe, reversible, local change — it affects only your machine and touches nothing on the servers or the public DNS. That combination of showing you the true post-cutover experience while changing nothing public is what makes it the ideal migration preview tool.

Why it’s the best preview method

The hosts file is the gold-standard preview method because it shows you the migrated site under your real domain name — and that matters more than it might seem. Websites, especially WordPress, generate links, load assets, and behave based on their domain, so a site that appears fine under a temporary URL or raw IP can hide URL and link problems that only surface under the real domain. The hosts file eliminates that blind spot.

Alternative preview methods each have this limitation. A host’s temporary URL serves the site under a different address, so any stored-URL issues (links or images pointing to the real domain) may be masked or behave differently than they will once live. The raw server IP is worse, often breaking domain-based links entirely. Both can make a site look more (or differently) broken or working than it actually will be after cutover.

So the hosts file is the truest preview because it replicates the exact condition of being live — your real domain resolving to the new server — for your computer alone. What you see through it is genuinely what visitors will see after cutover, which means the problems you catch (and the confirmation you get) are real and reliable. That fidelity is why experienced migrators reach for the hosts file over any other preview method: it is the closest thing to going live without actually going live.

Finding your new server’s IP

To create the hosts-file entry, you need the new host’s server IP address — the numeric address of the server where your migrated site now lives. This is the address you will map your domain to. You find it in your new hosting account or control panel, usually displayed prominently in the account overview or server information, often labelled as the server IP, shared IP, or dedicated IP.

If it is not obvious in the control panel, the new host’s welcome email or support documentation typically includes the server IP, and the host’s support can always tell you. You want the IP of the server hosting your migrated site specifically — for most shared hosting this is a single IP for your account. Note it down accurately, since a wrong IP means your hosts-file entry points nowhere useful.

So getting the new server’s IP is a matter of looking in your new hosting account’s overview or server-information section, or checking the welcome email or asking support. It is a single piece of information — the new server’s numeric address — and with it in hand, you have everything you need to write the hosts-file entry that maps your domain to the new host for your computer. Accuracy matters: double-check the IP, because the whole preview depends on pointing to the right server.

Editing the hosts file

Editing the hosts file means adding a single line mapping the new server’s IP to your domain. The file’s location and the way you edit it depend on your operating system, but the entry format is the same everywhere: the IP address, a space, then the domain.

• The entry format: a line like ‘ yourdomain.com’, and usually a second line for the www version, ‘www.yourdomain.com’, so both resolve to the new host.
• Location varies by OS: the hosts file lives in a system location that differs between Windows, macOS, and Linux — search your OS’s documentation for ‘edit hosts file.’
• Admin rights needed: because it’s a system file, you edit it with administrator/root privileges (e.g. opening your text editor ‘as administrator’).
• Save as plain text: the hosts file has no extension and must stay plain text — don’t let an editor add a .txt extension.

So you add the line(s) mapping your new server’s IP to your domain (and www), save the file (with admin rights, as plain text), and the override takes effect. You may need to flush your computer’s DNS cache or restart the browser for it to take hold immediately. Once it does, your computer resolves your domain to the new host, while the public DNS is untouched. The edit is a single line or two — the only fiddly parts are locating the file for your OS and editing it with the right privileges, both of which your OS’s documentation covers.

Previewing and testing through it

With the hosts-file entry in place, you simply visit your domain in your browser as normal — and you will be served the migrated site on the new host, under your real domain, because your computer is now resolving the domain to the new server. To everyone else, nothing has changed; they still reach the old site via the unchanged public DNS. You now have a private, realistic preview of the post-cutover state.

Use this to run your full pre-cutover testing checklist under true-to-live conditions: load a range of pages, check images and styling, click internal and external links (which now resolve exactly as they will after cutover), submit forms, test logins and checkout, and verify functionality. Because you are seeing the site under its real domain, any URL or link problems show up authentically, so you catch exactly what visitors would encounter — and can fix it before cutover.

So testing through the hosts file is just browsing your own domain, but seeing the new host’s version of it. This is where the hosts file pays off: it turns your normal browsing of your domain into a genuine test of the migrated site as it will actually behave live. Confirm everything works through this preview, fix anything that does not, and you can approach the cutover knowing the site is genuinely ready — verified under the exact conditions that will apply once the switch is made.

Cleaning up afterward

After you have finished testing — and especially after you cut over — you should remove the hosts-file entry, because leaving it in place can cause confusion later. Once the entry is there, your computer will keep resolving your domain to that specific IP regardless of any future DNS changes, which is helpful during the migration but misleading afterward.

The specific risk is that after cutover and any future changes, your computer would still be forcing your domain to the IP in the hosts file, so you might see a stale or wrong version of the site while everyone else sees the correct one — and you could spend time debugging a ‘problem’ that is really just your own leftover hosts entry. Removing the entry once you are done ensures your computer resolves your domain normally, like everyone else’s.

So when your testing is complete (or once the real cutover has propagated and you no longer need the override), delete the hosts-file entry you added and save the file, returning it to its original state. This is a small but important cleanup step, because a forgotten hosts entry is a classic source of self-inflicted confusion — ‘why does the site look different on my computer?’ The hosts file is a temporary tool for the migration window; remove your entry afterward, and your computer goes back to seeing your domain exactly as the rest of the world does.

FAQs

How do I use the hosts file to preview a migration?

Find your new host’s server IP (in your hosting account or control panel), then edit your computer’s hosts file to add a line mapping that IP to your domain (and the www version). Save it with admin rights as plain text, flush your DNS cache, and visit your domain — you’ll see the migrated site on the new host under your real domain while everyone else still sees the old. Remove the entry when done.

What is the hosts file?

A small text file on your computer that acts as a local, personal DNS override — your computer checks it before asking the internet’s DNS. An entry mapping a domain to a specific IP makes your machine (only) use that mapping regardless of public DNS. For migration, it lets you point your domain to the new server for yourself while the world still sees the old site.

Why is the hosts file the best way to preview a migration?

Because it shows the migrated site under your real domain name, exactly as it’ll behave once live — catching URL and link problems that a host’s temporary URL or the raw server IP can mask (since those serve the site under a different address, where stored-URL issues behave differently). It replicates the true post-cutover experience for your computer alone, so what you see is what visitors will get.

How do I find my new server’s IP for the hosts file?

Look in your new hosting account or control panel — the server IP (sometimes called shared or dedicated IP) is usually in the account overview or server-information section. If it’s not obvious, check the host’s welcome email or documentation, or ask support. You want the IP of the server hosting your migrated site; note it accurately, since the preview depends on pointing to the right server.

Where is the hosts file and how do I edit it?

Its location differs by operating system (Windows, macOS, Linux each store it in a system location — search your OS docs for ‘edit hosts file’). You edit it with administrator/root privileges since it’s a system file, add a line like ‘ yourdomain.com’ (plus a www line), and save it as plain text with no extension. You may need to flush your DNS cache or restart the browser for it to take effect.

Do I need to remove the hosts file entry afterward?

Yes. Once the entry is there, your computer keeps forcing your domain to that IP regardless of future DNS changes — helpful during migration, misleading afterward. Leaving it can make you see a stale version while everyone else sees the correct one, and debug a ‘problem’ that’s just your leftover entry. Delete the entry and save the file once testing is done or the real cutover has propagated.

The bottom line

The hosts file is the simplest and most powerful tool for previewing a migration, and it works because it is a local, personal DNS override: a tiny text file on your own computer that your machine consults before the internet’s DNS. Add an entry mapping your domain to the new host’s server IP, and your computer alone resolves your domain to the new server — so you see the migrated site under your real domain name while the entire rest of the world still sees the old site via the unchanged public DNS. That is exactly why it is the gold-standard preview method: because you view the site under its actual domain, you see precisely how it will behave once live, catching the URL and link problems that a host’s temporary URL or the raw server IP would mask by serving the site under a different address.

Using it is straightforward: find your new server’s IP in your hosting account, edit your computer’s hosts file (with admin rights, as plain text) to add a line mapping that IP to your domain and its www version, flush your DNS cache, and then simply browse your domain — where you will now be served the new host’s version. Run your full testing checklist through this preview, catching and fixing everything under true-to-live conditions before you touch DNS. Then, crucially, remove the entry when you are done or once the real cutover has propagated, because a forgotten hosts entry keeps forcing your domain to that IP and becomes a classic source of self-inflicted confusion — seeing a stale version while everyone else sees the right one. Point, preview, test, and clean up: the hosts file gives you the truest possible dress rehearsal for going live, changing nothing public in the process.

When you are ready, you can start with Hostinger and use code PROTIPS for the reader discount. The hosts file is a local DNS override on your computer: map your domain to the new server’s IP in it, and you see the migrated site under your real domain while the world still sees the old — the truest pre-cutover test, catching URL/link issues other previews mask. Find the new server IP, add a line (‘ yourdomain.com’ plus www) with admin rights as plain text, flush DNS, test — then remove the entry when done to avoid seeing a stale version later.