IP Checker

How to Use the IP Checker

1. Load the tool on your target network: Open this page from the specific network or connection whose IP you need to check — your home Wi-Fi, office network, mobile hotspot, or VPN connection each produce a different IP, so verify from the right one.
2. Read your public IPv4 address: The IPv4 address (formatted as four numbers separated by dots, e.g., 203.0.113.58) is your internet-facing address for the vast majority of services. Copy it using the copy button for use in firewall rules, SSH configs, or IT tickets.
3. Check the ISP field to confirm routing: If you are connected to a VPN, the ISP field should display your VPN provider's name — not your home or office ISP. If it still shows your home ISP, the VPN is not routing traffic correctly despite appearing connected.
4. Check for IPv6 if configuring dual-stack services: If you are setting up firewall rules for a server that accepts both IPv4 and IPv6, note both addresses. Failing to include an IPv6 rule when you have IPv6 connectivity can leave a gap in your access control configuration.
5. Repeat after each network change: IP addresses are assigned per connection session. After switching networks, reconnecting to a VPN, or restarting your router, refresh the page to see your updated IP before using it in any configuration.

Real-World Use Case

A security engineer at a fintech company works remotely and needs access to a production database server locked down to a whitelist of approved IPs. In the morning, they check their home IP (198.51.100.14) using this tool and submit it to the infrastructure team. By afternoon, their ISP has renewed their DHCP lease, assigning a new IP (198.51.100.87). When they try to connect, the database server refuses the connection — the old IP is whitelisted but the new one is not. They recheck their IP here, immediately identify the change, and send the updated IP to the infrastructure team. The IP checker made the diagnosis instantaneous rather than triggering a lengthy troubleshooting process with server logs and firewall rule audits.

Best Practices

• Always check IP before submitting for whitelisting: Dynamic IPs change without notice. Never rely on an IP you checked yesterday — always verify your current IP immediately before providing it for any access control configuration.
• Disconnect and reconnect VPN before re-checking: VPN connections sometimes establish partially, routing some traffic through the tunnel while other traffic uses the direct connection. Fully disconnect, wait a few seconds, reconnect, then check your IP to confirm the full tunnel is active.
• Use IPv4 for firewall rules unless explicitly dual-stack: Most firewall systems and access control lists handle IPv4 and IPv6 separately. Unless you specifically need IPv6 access, use the IPv4 address for whitelisting to avoid ambiguity and misconfiguration.
• Check both mobile data and Wi-Fi IPs separately: Your phone's mobile data IP and its Wi-Fi IP are completely different. If you need to whitelist your phone for remote access, check the IP from the specific interface that will be used to connect.
• Document the timestamp alongside the IP: When logging IP addresses for security audits, change records, or incident response, always record when the IP was checked — dynamic assignments make the time of capture an important detail for correlating with access logs.

Performance & Limits

• Instant detection: Your IP is read from the HTTP request headers the moment the page loads — there is no lookup delay, DNS resolution, or scanning involved in displaying your address.
• Single-check accuracy: The IP shown is your address at the exact moment of page load. If you are on a connection that rotates IPs frequently (some mobile carriers, certain CGNAT setups), the shown IP may differ slightly from what another service sees milliseconds later.
• Proxy detection: Standard HTTP proxies forward your original IP in the X-Forwarded-For header, which this tool reads. Properly configured transparent proxies may substitute their own IP, causing the tool to show the proxy's address rather than your originating IP.
• VPN split tunneling: If your VPN is configured for split tunneling (routing only some traffic through the VPN), your browser may use the non-VPN path to load this page, showing your real IP even though other applications are going through the VPN tunnel.
• Tor Browser limitation: Traffic through Tor exit nodes appears to originate from the exit node's IP — this tool will show the Tor exit node's address, not your actual IP. This is expected behavior for the Tor anonymity network.

Common Mistakes to Avoid

• Checking IP before enabling VPN, not after: A common mistake when verifying VPN function is checking IP, then connecting to VPN without refreshing. The page still shows the pre-VPN IP. Always refresh the page after the VPN connects to see the actual routing result.
• Assuming the ISP name confirms VPN is working: Some VPN providers use IP ranges registered under generic hosting company names, not the VPN brand. If the ISP field shows a data center company rather than your home ISP, the VPN is likely working — verify by checking the IP against your VPN provider's published server IPs.
• Providing the local area network IP instead of the public IP: Your device's network settings show a private RFC 1918 address (192.168.x.x or 10.x.x.x). This is useless for firewall whitelisting or remote access configuration. Only the public IP shown by an external IP checker like this one is the correct address to provide.
• Ignoring the IPv6 address when setting up SSH access: Modern Linux servers with IPv6 enabled will accept SSH connections on both IPv4 and IPv6. If you whitelist only your IPv4 address but connect via IPv6, access will be denied. Check both addresses and whitelist both when relevant.

Privacy & Security

• Checking your IP does not expose additional data: This tool reads exactly what your browser already sends to every website you visit — your source IP address. No additional fingerprinting, cookie tracking, or behavioral analysis is performed.
• IP checkers are standard operational security tools: Security professionals routinely verify their IP before and after VPN connections, proxy configurations, and firewall changes. Using an IP checker is a basic operational security (OpSec) step, not a privacy risk.
• HTTPS protects in-transit data: This page is served over HTTPS, ensuring the IP detection request and response are encrypted in transit — an ISP or network observer cannot inject false IP data into the response.
• No session storage or tracking: Your IP is displayed only for the current page session. No history of checked IPs is stored, no account is required, and no personally identifiable information is collected or retained.