How to preview a website on a new server before changing DNS: every method compared

One server usually hosts many sites and picks one by the domain name the browser sends, so http://203.0.113.10/ shows a default page or a certificate warning. Every method below sends the request to the new IP while saying “I want example.com”. They differ in who can see the result, on which devices, and how exact it is.

Your operating system reads the hosts file before it asks DNS. One line per hostname points your domain at the new server, on this computer only:

# Windows: C:\Windows\System32\drivers\etc\hosts  (edit as Administrator)
# macOS / Linux: /etc/hosts  (edit with sudo)
203.0.113.10   example.com
203.0.113.10   www.example.com

# Then flush the DNS cache
ipconfig /flushdns                                              # Windows
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder   # macOS
resolvectl flush-caches                                         # Linux with systemd-resolved

• Pros: exact, free and works for anything: private IPs, every port, the new server’s own certificate and headers. The hosts file generator writes the lines for you.
• Cons: one machine at a time, needs admin rights, impractical on iOS and Android, and easy to forget. A line left behind after the migration keeps you on the wrong server.
• Best for: a developer checking their own work, and the final check of HTTPS, security headers and third-party sign-in before the switch.

--resolve tells curl which IP to use for a hostname, so the request carries your real domain, including in the TLS handshake, and the certificate is checked:

# Status line and headers from the new server, over HTTPS
curl -sI --resolve example.com:443:203.0.113.10 https://example.com/

# The page title, to make sure it is your site and not a default page
curl -s --resolve example.com:443:203.0.113.10 https://example.com/ | grep -i "<title>"

# No certificate yet? -k skips verification; plain HTTP works with a Host header
curl -skI --resolve example.com:443:203.0.113.10 https://example.com/
curl -sI -H "Host: example.com" http://203.0.113.10/

Use -H "Host: …" only for plain HTTP: over HTTPS curl would still send the IP in the TLS handshake and check the certificate against it. On Windows, type curl.exe, because in Windows PowerShell 5.1 curl is an alias for Invoke-WebRequest.

• Pros: seconds, nothing to undo, scriptable, and it shows status codes, redirects and the certificate exactly as the server sends them.
• Cons: no rendering: HTML and headers only, and only for you.
• Best for: confirming the site is set up on the new server before you spend time on anything else, and checks in scripts or CI.

Many hosts give each account a temporary address on their own domain, and cPanel servers may serve an account at http://203.0.113.10/~username/ when the host has mod_userdir enabled. You can also add a record for a new name such as staging.example.com that points at the new server: it adds a hostname without touching the live records.

• Pros: an ordinary URL that works on any device and can be sent to anyone, with no extra service.
• Cons: the site is answering for a different hostname. WordPress and most CMSs redirect to the domain stored in their settings, which still points at the old server, and absolute links and cookies follow the real domain too. Fixing that means a search-and-replace you must reverse before launch. Many hosts disable ~user URLs, and HTTPS is on the temporary name, not on your domain.
• Best for: static sites and apps that use relative URLs, or a host’s own handover when nothing else is available.

Chrome and other Chromium-based browsers accept a start-up switch that maps hostnames to an IP for that browser session only. A separate profile folder makes sure a new instance starts with the rule:

# Windows (Command Prompt)
"C:\Program Files\Google\Chrome\Application\chrome.exe" --user-data-dir=%TEMP%\chrome-preview --host-resolver-rules="MAP example.com 203.0.113.10, MAP www.example.com 203.0.113.10"

# macOS
open -na "Google Chrome" --args --user-data-dir=/tmp/chrome-preview --host-resolver-rules="MAP example.com 203.0.113.10, MAP www.example.com 203.0.113.10"

# A resolver for your whole network (dnsmasq; also covers subdomains)
address=/example.com/203.0.113.10

The last line is the same idea one level up: a local resolver such as dnsmasq, or a local DNS record in Pi-hole, answers with the new IP for every device that uses it, including phones on that Wi-Fi, as long as they use the network’s DNS rather than their own private DNS. Browser extensions cannot edit the hosts file; some preview services offer one as a shortcut to their links (hosts.click lists a Chrome extension; DNSPeek has none yet).

• Pros: no system files edited, nothing left behind when you close the browser, and an exact response with the real domain and certificate.
• Cons: the Chrome switch is desktop-only and easy to get wrong if Chrome is already running with the same profile. A resolver needs someone to run it, and it only helps people on your network.
• Best for: developers who want exact behaviour without touching the hosts file, and teams testing on real devices in one office.

A preview service gives you an HTTPS link on its own domain. The service connects to the IP you entered, asks for your real domain, and rewrites links, redirects and cookies so visitors stay inside the preview. It is the only method here a client can use without help.

What the services themselves state, as of October 2026 (details on DNSPeek vs SkipDNS, DNSPeek vs Peek-DNS and DNSPeek vs hosts.click):

• Pros: phones, tablets and clients open it like any link, there is nothing to install or undo, and a password or expiry date keeps it under control.
• Cons: a proxy sits in the middle. DNSPeek, for example, removes Strict-Transport-Security, Content-Security-Policy and X-Frame-Options and adjusts cookie flags so the preview works on its own address; sign-in with Google and hosted payment pages return to your real domain; firewalls on the new server may challenge proxy traffic; and only public IPs can be reached. See what previews can’t do.
• Best for: client and stakeholder review, mobile checks, and anyone who should not be asked to edit system files.

• Solo developer, your own laptop: curl --resolve, then the hosts file or the Chrome switch. Here they are simply the better choice: exact, free, no third party in the path. Use a preview link only for your phone.
• Agency with client sign-off: a password-protected preview link. The client never touches system files; you keep the hosts file for checking HTTPS, headers and sign-in, which a proxy changes. See getting client sign-off before launch and DNSPeek for agencies.
• Hosting provider moving customers: temporary URLs break most CMSs, so send preview links, created through the API or a prefilled /new?domain=…&ip=… link. If you need a button inside cPanel today, SkipDNS and hosts.click list panel plugins; DNSPeek does not have them yet. See DNSPeek for hosting providers.

Most migrations combine an exact check for yourself with a link for everyone else. More on that pair: hosts file vs preview link; the rest of the move: the website migration checklist.

1. 1

   Step 1: Get the new server’s IP

   Take it from the new host’s welcome email or control panel, not from a lookup of your domain. See Find your server IP.

2. 2

   Step 2: Check that the server answers for your domain

   Run curl -sI --resolve example.com:443:203.0.113.10 https://example.com/. A 200 or a redirect to your own domain means the site is set up; a default page means it is not yet.

3. 3

   Step 3: Look at it yourself in a browser

   Add hosts entries with the hosts file generator or start Chrome with --host-resolver-rules, then click through the key pages, forms and the admin area.

4. 4

   Step 4: Share a preview link with whoever signs off

   Enter the domain and IP on the new preview form, set a password if the site is sensitive, and send the link to your client or team.

5. 5

   Step 5: Undo your overrides after the switch

   Remove the hosts lines or close the Chrome profile, then confirm public DNS has moved with the DNS propagation checker.