Quality breakdown

Detailed samples

We contact only ports 80 and 443. Private IPs, localhost, and cloud metadata are blocked. Cookie values are hidden.

1. Who we are and what this is

IPSpeedPing is a free public website that shows (a) information derived from the public IP address your device uses to reach us, (b) an estimate of download/upload performance to our server, and (c) public technical facts about a hostname you type (DNS, TCP 80/443 timing, TLS, HTTP headers, RDAP). We are not an ISP, not a court, not a law-enforcement agency, and not a licensed broadband measurement lab.

2. Binding agreement

Accessing or using any page, tool, or API of this site is your acceptance of these Terms. Continued use after we post changes is acceptance of the new Terms. We may change the Terms at any time by updating this page. The date above is the version date.

3. Eligibility

You must be old enough to form a binding contract in your country (18 in India). You may not use the site if doing so is illegal where you are.

4. Informational use only

All numbers, maps, ISP names, cities, scores, certificates, and “up/down” states are estimates and opinions generated by software. They can be wrong, incomplete, delayed, or misunderstood. They are not:

• proof of anyone’s identity, home address, or guilt;
• an official TRAI, FCC, or ISP quality-of-service measurement;
• a security audit, penetration test, or legal notice;
• advice (legal, technical, or otherwise).

5. Your responsibilities

• You will use the IP tool only to inspect your own connection.
• You will use the website probe only on hosts you are allowed to check (your site, or a public homepage). You will not use it to attack, harass, scan, or bypass security.
• You will not try to reach private IPs, localhost, cloud metadata, or ports other than 80 and 443 (the server already blocks these).
• You will not automate abusive traffic, scrape in a way that harms the service, or reverse-engineer to build an attack tool.
• You accept that geolocation may be tens of kilometres off and must not be used to accuse, dox, or locate a person.

6. No warranty

THE SITE IS PROVIDED “AS IS” AND “AS AVAILABLE”, WITHOUT WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, ACCURACY, AND NON-INFRINGEMENT. We do not warrant that the site will be uninterrupted, error-free, or secure.

7. Limitation of liability

To the maximum extent permitted by applicable law (including Indian law), the operator of IPSpeedPing, its owners, and contractors are not liable for any indirect, incidental, special, consequential, exemplary, or punitive damages, or for lost profits, data, goodwill, or business interruption, arising from your use of (or inability to use) the site or from reliance on any result. Our total liability for any claim relating to the site shall not exceed INR 1,000 (one thousand Indian rupees) or the amount you paid us in the last 12 months (which is zero if the site is free), whichever is greater. Some jurisdictions do not allow certain limitations; in those places our liability is limited to the smallest amount the law allows.

8. Indemnity

You will defend and indemnify us against claims, losses, and costs (including reasonable legal fees) arising from your misuse of the tools, your violation of these Terms, or your violation of any law or third-party right.

9. Third-party services and ads

The site may show advertising and may call third-party APIs (geolocation, DNS, RDAP). Those parties have their own terms. We are not responsible for their content or outages. Clicking an ad or affiliate link is your choice.

10. Intellectual property

The IPSpeedPing name, logo, and site design are ours. You may not copy the service as a competing clone using our branding. You may quote short factual results for personal use.

11. Suspension

We may rate-limit, block, or shut down any use that looks abusive, without notice.

12. Governing law

These Terms are governed by the laws of India. Courts of competent jurisdiction in Gujarat, India shall have exclusive jurisdiction, subject to any mandatory consumer-protection rights you have in your home country.

13. Contact

Legal notices: legal@ipspeedping.com (create this mailbox on your domain). Also see Privacy and Disclaimer.

1. What we collect

• Public IP address your device uses to reach this site (required for the connection to work).
• Standard HTTP headers your browser sends (User-Agent, language, etc.).
• Tool inputs you type (a hostname for the probe).
• Speed-test bytes — random data, discarded after the measurement. We do not store the payload.
• A local preference cookie / localStorage for language, cookie choice, and “I agreed to the Terms”.
• If you accept advertising: cookies and identifiers set by the ad partner (for example Google AdSense).

2. What we do with it

Show you your own IP/ISP/geo estimate; measure throughput to our server; look up public DNS/TLS/HTTP/RDAP for a host you named; prevent abuse (rate limits); remember language and consent; after you opt in, show ads.

3. What we do not do

• We do not sell a searchable “who visited” database of people.
• We do not claim your street address, name, phone, or MAC from an IP.
• We do not display cookie values, tokens, or private RDAP contacts from probed sites.
• We do not use the probe as a port scanner or vulnerability scanner.

4. Legal bases (where that language applies)

India DPDP Act 2023 and similar laws: we process identifiers that can relate to a person for providing the service you requested, security, and — with consent — advertising. GDPR/UK GDPR (if you are in those regions): legitimate interests for security logs and the core tool; consent for non-essential cookies and ads.

5. Retention

Server abuse/security logs: up to 90 days. Browser localStorage stays until you clear it. Ad partners have their own retention.

6. Third parties

Geolocation APIs (for example ip-api / ipwho.is), public RDAP/DNS, and — if you accept ads — the advertising network. Their privacy policies apply to data they receive.

7. Your choices

You can refuse advertising cookies (Essential only). You can clear site data in the browser. You can email privacy@ipspeedping.com to ask us to delete logs we can still identify. Create that mailbox before launch.

8. Children

The site is not directed at children under 13 (or 18 where local contract law requires it).

9. International transfer

Our host (for example Railway) and APIs may process data outside India. By using the site you understand that.

See also Terms and Disclaimer.

IP and location

A public IP identifies a network, not a person. City, postal code, and coordinates are commercial guesses and are often wrong by many kilometres. We never claim to reveal a house, a name, or a phone number. Using our pages to harass, dox, threaten, or falsely accuse someone is forbidden and may be a crime. We are not responsible for how you interpret or share a result.

Speed test

Mbps, ping, jitter, and loss are measured to our server at the moment you click. They are not your ISP’s advertised plan, not a TRAI/FCC filing, and not a guarantee you can use in a billing dispute. Wi-Fi, other devices, VPN, browser extensions, and time of day all change the number. On localhost the test measures your PC to itself and will look unrealistically fast.

Website probe

We only contact public ports 80 and 443. We are not scanning you for vulnerabilities and we are not certifying that a site is safe. A “200 OK” does not mean the site is honest. A timeout does not mean the site is “down for everyone”. Do not probe machines you are not allowed to touch. Misuse can violate the Information Technology Act, 2000 and similar laws abroad. You are solely responsible for the hostnames you enter.

No legal action based on our output

By using the site you agree that you will not bring any claim against the operator, owners, or contractors of IPSpeedPing arising from (i) inaccuracy or delay of results, (ii) ads or third-party links, (iii) downtime, (iv) your or anyone else’s reliance on a result, or (v) your misuse of the tools — except to the extent a court holds that such a waiver is unenforceable. Where a waiver is unenforceable, liability is limited as stated in the Terms.

Availability

We may change, rate-limit, or discontinue any tool without notice.

Full contract: Terms of use. Data: Privacy policy.

IP: public address, ISP, ASN, approximate city, timezone, your own browser headers and WebRTC candidates. Never another person’s identity or street address.

Speed: download, upload, idle/loaded latency, jitter, loss estimate, ISP of the client. Not an official broadband measurement.

Probe: public DNS, TCP 80/443 timing, TLS certificate metadata, HTTP status and public headers (cookie values hidden), redacted RDAP. Not a port scan.

IPSpeedPing (ipspeedping.com) is operated as a free website. We offer three tools: what is my IP and ISP, an internet speed test, and ping a website (DNS, TLS, HTTP). We are not an ISP, not a court, and not an official broadband lab.

We built the product to show useful public facts and to refuse doxxing and port scanning. Results are estimates. Read the Disclaimer and Terms before you rely on a number.

The site may show advertising (Google AdSense) after you agree. Ads help keep the tools free.

General: hello@ipspeedping.com

Privacy / data requests: privacy@ipspeedping.com

Legal: legal@ipspeedping.com

We try to reply within a few working days. Do not send malware samples or ask us to hack, trace, or dox someone.

Every device that talks to the internet needs an address to send and receive data — that address is an IP address, short for Internet Protocol address. It works a bit like a postal address: when a website sends your browser a page, it addresses the reply to your IP address so the reply knows where to go. Without one, there would be no way for a reply to find its way back to you specifically, out of billions of connected devices.

Public vs private

Most homes and offices only have one public IP address, issued by the ISP, which the wider internet can see. Behind that single public address, a router hands out private addresses (typically starting with 192.168. or 10.) to each phone, laptop, and smart TV in the building. Those private addresses are invisible to the outside world — a website only ever sees your router's one public address, shared by everyone on your network. This is why our My IP tool shows one address even if five people in your house are online at once.

Dynamic vs static

Most home connections use a dynamic IP: your ISP can change it whenever it wants (a modem restart, network maintenance, or just periodically). Businesses sometimes pay for a static IP that never changes, useful for running a server. If your "IP address" seems to change every few days, that is completely normal for a dynamic connection.

What it actually reveals

A public IP address can reasonably tell a website: which internet provider you're on, roughly which city or region you're in (often accurate to tens of kilometres, not your exact building), and whether the address belongs to a residential connection, a mobile network, or a hosting company. It cannot reveal your name, phone number, or street address. That information sits in your ISP's private subscriber records, which are not published anywhere on the public internet — accessing them legally requires a court order or warrant served on the ISP, not a lookup tool.

CGNAT complicates things further

Many mobile networks and some broadband ISPs now use Carrier-Grade NAT (CGNAT), where hundreds or thousands of customers share a single public IP address at once, because the pool of available IPv4 addresses ran out years ago. If you're behind CGNAT, the IP address a website sees might correspond to a large group of unrelated customers, not just you — one more reason an IP address alone is a weak way to identify a specific person.

How long does an IP address stay "yours"?

Most home connections get their address through DHCP, a protocol that leases you an address for a limited time rather than assigning it permanently. Depending on the ISP, that lease might renew quietly every few hours without changing anything, or it might hand you a genuinely different address the next time your router reconnects — after a power cut, a firmware update, or simply because the ISP recycles addresses periodically. Neither behaviour means anything is wrong; it's just how dynamic addressing works. If you need an address that never changes (running a home server, for example), that's what a static IP add-on from your ISP is for.

Can someone "track you in real time" from an IP address alone?

This is one of the most exaggerated claims about IP addresses, usually from crime dramas rather than reality. Knowing someone's IP address does not give a stranger your live GPS position, does not let them see your screen, and does not let them access your files unless a specific service on your device is separately misconfigured to accept outside connections. At most, a public IP address narrows someone down to an ISP and a rough metro area — the same kind of resolution you'd get from a phone's area code, not a location pin. The far more common way people actually get "found" online is through information they voluntarily share (usernames, photos with visible landmarks, social media check-ins), not through IP addresses.

See your own address, ISP, and approximate location on the My IP & ISP tool.

The internet's original addressing system, IPv4, was designed in the early 1980s using 32-bit numbers — written as four numbers separated by dots, like 203.0.113.42. That format allows for about 4.3 billion unique addresses. That sounded limitless in 1981. It is nowhere near enough for a planet with billions of phones, laptops, routers, and smart devices, and the pool of available IPv4 addresses effectively ran out years ago.

Enter IPv6

IPv6 uses 128-bit addresses instead, written as eight groups of hexadecimal digits like 2401:4900:1c1f:af59::1. That is enough addresses — roughly 340 undecillion of them — to give every grain of sand on Earth its own address many times over. IPv6 was never going to run out; it was designed with headroom that IPv4 never had.

Why hasn't everyone switched?

Upgrading a global network is slow. Every router, ISP, and piece of network equipment has to support the new protocol, and IPv4 and IPv6 don't talk to each other directly — a device needs "dual-stack" support to use both. Instead of an abrupt cutover, most networks quietly patched around the IPv4 shortage using Carrier-Grade NAT (CGNAT), letting many customers share one public IPv4 address. That workaround reduced the urgency to migrate, which is part of why, decades after IPv6 was finalized, a large share of global traffic still runs on IPv4.

Does it matter to you?

Mostly no — your devices and browser handle this automatically, usually preferring IPv6 when both the device and the website support it, and quietly falling back to IPv4 otherwise. The practical difference shows up in a few places: IPv6 addresses generally aren't shared between customers the way CGNAT'd IPv4 addresses often are, so services that dislike shared addresses may behave slightly differently. Our My IP tool shows both your IPv4 and, if your connection has one, your IPv6 address — many Indian mobile and Wi-Fi connections still show "not seen" for IPv6, which simply means that network hasn't rolled it out yet, not that anything is broken on your end.

The exhaustion timeline, briefly

The regional registries that hand out IPv4 blocks ran dry at different times: Asia-Pacific's registry (APNIC) exhausted its free pool back in 2011, Europe's (RIPE NCC) in 2019, and North America's (ARIN) shortly after. Since then, "new" IPv4 addresses mostly come from a secondary market — companies buying and selling blocks they're no longer using — rather than fresh allocation, which is part of why IPv4 addresses have effectively become a scarce, tradeable resource rather than a free, unlimited one.

A common myth: is IPv6 more "private"?

Not inherently. Early IPv6 implementations generated addresses from a device's fixed hardware (MAC) address, which meant a device could theoretically be recognized across different networks by its IPv6 address — the opposite of private. Modern operating systems fixed this with "privacy extensions" that generate random, rotating IPv6 addresses instead, but it's a good example of why "newer protocol" doesn't automatically mean "better privacy" without the right defaults actually being enabled.

Quick way to tell which one you're using

Open our My IP tool: if the IPv6 field shows a real address rather than "not seen," your connection supports dual-stack and is capable of using both. Which one an individual website connection actually uses depends on whether that site's server supports IPv6 too — you can't fully control that from your end.

Check which you have on the My IP & ISP page.

A VPN (virtual private network) routes your internet traffic through a server operated by the VPN provider before it reaches its destination. Websites you visit see the VPN server's IP address instead of yours, and the connection between your device and the VPN server is encrypted. That's genuinely useful — but it's worth being precise about what it does and doesn't do.

What it does change

• The public IP address (and therefore the approximate location and ISP) that a website sees — it now belongs to the VPN provider, not you.
• What your own ISP or a snooping party on the same public Wi-Fi can see about which sites you're visiting, since your traffic is encrypted to the VPN server.

What it does not change

• Sites you're logged into. If you log into an account, that site knows who you are regardless of which IP address you're connecting from.
• Browser fingerprinting. Your browser, screen size, fonts, and installed extensions can still create an identifiable pattern independent of your IP.
• DNS or WebRTC leaks. A misconfigured VPN can still send DNS lookups or WebRTC connection data outside the encrypted tunnel, quietly revealing your real IP even while the VPN is "on."

How to actually check it's working

Open our My IP tool before turning the VPN on, note the IP and city shown, then turn the VPN on and refresh. If the address, ISP, and approximate city all change to match the VPN server's location, the basic tunnel is working. The page also runs a WebRTC check — if it lists a public IP address that doesn't match your VPN's address, that's a WebRTC leak, and worth reporting to your VPN provider or disabling WebRTC in your browser settings.

A VPN is not anonymity

A VPN provider can, in principle, see and log what you do through their servers, so switching who you trust with that visibility (your ISP vs. the VPN company) is really what's happening, not the elimination of trust entirely. Read a VPN provider's logging policy before assuming "no logs" claims are independently verified.

Free VPNs come with a different cost

Running VPN servers costs real money, so a "free" VPN is paying for that infrastructure somehow — commonly through showing ads, selling anonymized (or not-so-anonymized) usage data, or in worse cases, bundling malware or reselling your bandwidth to other users of the same product. A reputable paid VPN with a clear, published privacy policy is generally a safer bet than a free one with no stated business model.

Split tunneling

Many VPN apps offer "split tunneling" — routing only some apps or sites through the VPN while everything else uses your normal connection directly. Useful for keeping local-network devices (like a printer or smart TV) reachable while the VPN is on, or for keeping bandwidth-heavy background traffic off the (often slower) VPN tunnel.

When a VPN genuinely won't help

A VPN protects the network path between you and its server — it does nothing for malware already running on your device, a phishing page that tricks you into typing a password, or an account that was compromised through a leaked password from an unrelated data breach. It's one layer of a security posture, not a substitute for the others.

VPN vs. proxy vs. Tor

These get conflated often, but they're different tools. A plain proxy typically reroutes just your browser traffic, usually without encryption, and is easy to detect and block. A VPN encrypts and reroutes essentially all of your device's traffic at the operating-system level. Tor routes traffic through at least three independent volunteer-run relays with layered encryption, trading noticeably more latency for a much stronger anonymity model where no single relay operator can see both who you are and what you're accessing — a different threat model than a VPN, which concentrates that trust in one provider instead.

Test your own connection on the My IP & ISP tool.

Every time you type a domain name like example.com into a browser, something has to translate that human-readable name into the numeric IP address computers actually use to connect. That translation system is DNS — the Domain Name System — and it runs, invisibly, before nearly every request on the internet.

The lookup chain

1. Local caches first. Your browser and operating system both keep a short-term memory of recent lookups. If you visited the site minutes ago, the answer might already be cached and no network lookup happens at all.
2. Recursive resolver. If nothing is cached, your device asks a resolver — usually run by your ISP, or a public one like 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare) if you've configured one manually.
3. Root servers. The resolver asks one of the internet's root servers, which don't know the answer but know which server handles the .com (or .in, .org, etc.) part of the name.
4. TLD servers. That top-level-domain server points the resolver toward the specific authoritative nameserver responsible for example.com.
5. Authoritative answer. The authoritative nameserver returns the actual IP address, which the resolver hands back to your device — and usually caches for next time.

All of that typically happens in a few dozen milliseconds, often faster than the time it takes to read this sentence.

Common record types

A domain's DNS zone can hold several kinds of records, each answering a different question: A records map a name to an IPv4 address, AAAA to an IPv6 address, CNAME points one name to another name, MX tells the internet which server handles email for the domain, NS lists which servers are authoritative for the zone, and TXT holds arbitrary text — often used for verifying domain ownership or publishing anti-spam policies like SPF.

Why DNS lookups sometimes fail

A "site can't be reached" error is very often a DNS problem, not the target site actually being down — a typo in the domain, an expired domain registration, or a resolver that's slow or blocked can all produce that error while the destination server is perfectly healthy.

TTL: how long an answer gets remembered

Every DNS record is published with a Time To Live (TTL), in seconds, telling resolvers how long they're allowed to cache the answer before asking again. A short TTL (say, 300 seconds) means changes to a site's DNS propagate quickly but adds slightly more lookup traffic; a long TTL (a day or more) reduces lookup traffic but means a DNS change can take a long time to fully take effect everywhere, since caches around the world are all still holding the old answer until their TTL expires. This is exactly why changing a domain's DNS — like pointing it at a new host — is usually described as taking anywhere from minutes to a day or more to "propagate."

Why changing your DNS resolver can feel faster

Your ISP's default resolver isn't always the fastest or most reliable one available to you. Public resolvers like 1.1.1.1 or 8.8.8.8 often respond faster because they run large, well-provisioned infrastructure and sit closer to major internet exchange points. Switching resolvers doesn't change your download speed, but it can reduce the small delay before a page even starts loading, and some public resolvers also block known malicious domains as a side benefit.

DNS privacy: who sees your lookups

Traditional DNS queries are sent unencrypted, meaning your ISP (and anyone else on the network path) can see which domains you're resolving, even if the actual page content is encrypted with HTTPS afterward. Newer standards — DNS over HTTPS (DoH) and DNS over TLS (DoT) — encrypt the lookup itself, which is why most modern browsers now support enabling one of them directly in settings.

Our website probe tool shows a domain's live A, AAAA, CNAME, MX, NS, TXT, and SOA records directly.

Download speed measures how much data arrives per second — it decides how fast a video buffers. It has almost nothing to do with how responsive a connection feels in a video call or an online game. That's what these three metrics measure instead.

Ping (latency)

Ping measures how long it takes a small packet to travel to a server and back, in milliseconds. A 200 Mbps connection with 180 ms ping will still feel sluggish in anything that needs quick back-and-forth exchanges — the bandwidth was never the bottleneck. Under about 30 ms is excellent, under 60 ms is good for most video calls and games, and above 120 ms starts to feel noticeably laggy.

Jitter

Jitter is how much your ping varies from one measurement to the next. A steady 80 ms ping is easier for a voice call to handle smoothly than one that swings between 20 ms and 150 ms, even though the average might be similar — voice and video codecs need a fairly predictable rhythm of packets, and unpredictable timing is what causes audio to stutter or drop out.

Bufferbloat

Most routers and modems queue up outgoing data in a buffer before sending it, so a sudden burst of traffic doesn't get dropped. The problem: many devices ship with buffers sized far larger than they need to be. When a large download or upload fills that oversized buffer, every other packet — including the ones carrying your video call or game — gets stuck waiting in the same queue. The result is your ping suddenly jumping from 20 ms to 300 ms the moment something starts downloading in the background, even though your download speed itself looks fine. This is bufferbloat, and it's a common, often invisible reason a connection "feels bad" despite a fast plan.

What good numbers look like together

A well-behaved connection keeps ping low and steady, and keeps that ping from inflating by more than roughly 50 ms when a download or upload is running in the background. If loaded ping jumps by hundreds of milliseconds, it's worth checking whether your router supports Smart Queue Management (SQM) or similar bufferbloat mitigation — many modern routers do, but don't enable it by default.

Practical ways to lower your own ping

A wired Ethernet connection almost always beats Wi-Fi for latency and consistency, since Wi-Fi introduces its own retransmission delay and is shared with every other wireless device nearby, including neighbours' networks on the same channel. Closing background apps that sync or upload (cloud backup, game updates, torrent clients) removes competing traffic from your own connection's queue. And for anything latency-sensitive, connecting to the geographically closest available server matters more than raw bandwidth — a game server across the ocean will have a latency floor no amount of Mbps can fix, set purely by the speed of light over that distance.

Why our test uses TCP, not ICMP

Classic command-line "ping" uses ICMP echo packets, which many networks and firewalls deliberately deprioritize or block since they're a common target for abuse. Browsers also can't send raw ICMP at all. Instead, this site times a TCP connection to the server on the same ports (80/443) your browser actually uses for everything else — a more representative measurement of the latency you'll actually experience loading a page, even if the specific number differs slightly from a command-line ping to the same host.

Our speed test measures all three — including a dedicated bufferbloat step — alongside download and upload.

The padlock icon next to a website's address means the connection is encrypted using TLS (Transport Layer Security — the modern successor to the older SSL protocol, though people still say "SSL" out of habit). Encryption alone isn't the whole story, though: TLS also has to prove that the server you're talking to is actually who it claims to be, and that's where certificates come in.

What a certificate actually is

A TLS certificate is a small, digitally signed file that says, in effect, "a trusted third party confirms that this public key belongs to this domain name." When your browser connects to a website, the server presents its certificate, and your browser checks whether it was signed by a Certificate Authority (CA) that the browser already trusts — a list baked into the browser and operating system.

The chain of trust

Certificates are rarely signed directly by a CA's most sensitive "root" key. Instead there's usually a chain: a root certificate (trusted implicitly) signs an intermediate certificate, which signs the actual website's certificate. Your browser walks up that chain, link by link, until it reaches a root it already trusts. If any link is broken, expired, or doesn't match the domain name you're actually visiting, the browser refuses the connection and shows a warning instead of silently proceeding.

Why "not secure" appears

A few common causes: the site is plain HTTP with no certificate at all; the certificate has expired; the certificate was issued for a different hostname than the one in your address bar (for example, a certificate for example.com being served on www.example.com); or the chain is broken because an intermediate certificate wasn't included. None of these necessarily mean the site is malicious — often it's a simple configuration or renewal mistake — but the browser can't tell the difference, so it warns you either way.

Free, automated certificates changed everything

Getting a certificate used to cost money and require manual renewal every year. Services like Let's Encrypt now issue free certificates automatically, re-issuing them every 90 days without a human involved, which is a big part of why most of the web now defaults to HTTPS.

Not all certificates prove the same thing

Certificates come in a few validation levels. Domain Validated (DV) — the vast majority today, including free ones — only confirms that whoever requested the certificate controls the domain name; it says nothing about who runs the business behind it. Organization Validated (OV) and the now largely retired Extended Validation (EV) certificates involved the certificate authority actually checking business registration paperwork. Either way, browsers no longer visually distinguish these levels the way they once did — a padlock today only ever confirms "this connection is encrypted and the domain name matches," never "this business is legitimate." A convincing phishing site can have a perfectly valid DV certificate for its own look-alike domain.

Mixed content warnings

A page can be loaded over HTTPS but still pull in a handful of resources — an image, a script — over plain HTTP. Browsers flag this as "mixed content" because that one insecure resource is a foothold for tampering, even if the main page itself is encrypted. Fixing it usually just means updating a few hardcoded http:// links to https://.

Our website probe tool inspects a site's live certificate chain, issuer, validity dates, and protocol version.

Every registered domain and allocated block of IP addresses has a record of who registered it, held by a registry or registrar. For decades, the way to look that up was WHOIS — a protocol from the early 1980s that predates the modern web by a decade. It still works, but it's showing its age, and it's gradually being replaced.

What was wrong with WHOIS

WHOIS returns plain, unstructured text, and every registry formats that text slightly differently — there was never an agreed-upon standard, so software trying to parse a WHOIS response had to guess at each registry's particular layout. It also has no built-in way to redact personal information selectively, which became a real problem once privacy laws like GDPR required registries to stop publishing registrants' personal contact details by default.

RDAP: the replacement

RDAP (Registration Data Access Protocol) is a modern, standardized replacement — it returns structured JSON instead of freeform text, works over regular HTTPS, and has consistent, predictable field names across every registry that supports it. Most major registries have adopted it, and it's steadily replacing WHOIS as the primary lookup method.

What's deliberately hidden now

Both WHOIS and RDAP results today typically omit a domain's personal registrant details — name, email, phone, and home address — for individual registrants, replacing them with the registrar's redaction notice instead. What's usually still visible: the registrar's name, when the domain was created and when it expires, which nameservers it uses, and whether DNSSEC is enabled. For IP address blocks, RDAP typically shows which organization was allocated the range and its size, without exposing which specific customer is using a given address within it.

Why this matters for security research

Even with personal data redacted, RDAP/WHOIS data is still genuinely useful — confirming who operates a domain's infrastructure, spotting recently-registered domains (a common phishing signal), and checking whether a domain's registration is about to lapse.

Privacy/proxy registration services

Even before registries started redacting personal data by default, many registrants paid for a "WHOIS privacy" add-on from their registrar, which listed the registrar's own proxy contact details instead of the registrant's. That practice predates the current privacy-law-driven redaction and still exists in some registries as an extra layer — meaning even a fully "public" WHOIS record from years ago may have never actually shown the real registrant.

Looking a domain up yourself

Command-line tools like whois example.com still work on most systems for a quick check, and RDAP has an equivalent bootstrap system at rdap.org that automatically finds the right registry to ask, which is exactly what powers this site's own probe tool. Rate limits are common on both — registries throttle automated bulk lookups to prevent scraping, so a lookup tool that queries too aggressively may get temporarily blocked.

What a lookup can tell you about IP address blocks too

RDAP isn't only for domain names — the same protocol covers IP address allocations. Looking up an IP address's RDAP record shows which organization was allocated that block (an ISP, a hosting company, a university), roughly how large the block is, and which regional registry manages it (ARIN for North America, RIPE NCC for Europe, APNIC for Asia-Pacific, and so on). This is genuinely useful for, say, figuring out whether traffic hitting a server is coming from a residential ISP or a datacenter/hosting provider — a common early signal in abuse investigation, without needing to identify any specific individual.

When a lookup comes back empty

Not every result is a clean success. A domain that's genuinely unregistered returns a "not found" response. A newly registered domain might not have propagated into a registry's RDAP database yet. And some smaller or older country-code registries still haven't adopted RDAP at all, meaning a lookup tool has to fall back to legacy WHOIS, or simply can't return structured data for that particular domain ending.

Our website probe tool pulls a domain's and its IP block's RDAP record automatically, with personal fields already stripped.

Beyond the page content itself, a web server can send extra instructions to the browser in HTTP response headers — small pieces of text that tell the browser how to treat the page defensively. None of these are visible on the page itself, but they meaningfully affect how much damage a compromised or malicious script can do.

Strict-Transport-Security (HSTS)

Tells the browser "always use HTTPS for this domain, for the next N seconds, even if someone types plain http://." Without it, a network attacker on public Wi-Fi could try to silently downgrade a visit to unencrypted HTTP before the browser ever gets a chance to redirect.

Content-Security-Policy (CSP)

Restricts which sources of scripts, styles, images, and other content a page is allowed to load from. A strong CSP is one of the most effective defenses against cross-site scripting (XSS) attacks, because even if an attacker manages to inject a malicious script tag, the browser will refuse to execute it if it doesn't come from an allowed source.

X-Frame-Options

Controls whether the page can be loaded inside an <iframe> on another site. This blocks "clickjacking" attacks, where a malicious site overlays invisible buttons from your site inside a frame to trick visitors into clicking something they didn't intend to.

X-Content-Type-Options

Set to nosniff, this stops the browser from guessing a file's type based on its content instead of trusting the server's declared Content-Type. Without it, a browser might, for example, execute a file as JavaScript that was uploaded as an "image," if the actual bytes inside look script-like.

Referrer-Policy

Controls how much of the previous page's URL gets sent along when a visitor clicks a link to somewhere else — useful for not leaking sensitive query parameters (like a search term or session identifier embedded in a URL) to third-party sites you link out to.

Permissions-Policy

Explicitly turns off browser features a page doesn't need — camera, microphone, geolocation — so that even a compromised third-party script embedded on the page can't silently request access to them.

Headers vs. meta tags

A few of these can technically also be set via an HTML <meta> tag instead of a real HTTP header, but that's a weaker guarantee — a header is enforced by the browser before the page's HTML is even parsed, while a meta tag only takes effect once the browser has already started reading the page, leaving a small window where a malicious injected script could run first. Sending them as real HTTP headers, the way a properly configured server should, closes that gap.

Checking your own site

None of these headers are visible by looking at a rendered page — you have to inspect the actual HTTP response, either through browser developer tools (Network tab → click a request → Headers) or with a dedicated checker. That's exactly what this site's own probe tool automates for any public URL, showing which of these headers are present, missing, or misconfigured.

Why some sites don't send all of them

Adding a strict Content-Security-Policy in particular can break a site if done carelessly — third-party widgets, analytics scripts, and ad networks all need to be explicitly allow-listed, and forgetting one silently breaks that feature instead of raising an obvious error. This is a common reason smaller sites skip CSP entirely rather than get it wrong: an absent header just means "no extra protection," while a misconfigured one can mean "half the page doesn't work." The safer headers — X-Content-Type-Options, Referrer-Policy — have essentially no downside and there's rarely a good reason to omit them.

These headers protect the browser, not the server

It's worth being clear about the boundary: everything above defends the visitor's browser from being tricked by malicious content on the page. None of it substitutes for securing the server itself — patching software, validating input, and access control are a separate job. A site can have a perfect security header report and still be running vulnerable server-side code, and vice versa.

Our website probe tool checks which of these headers a site actually sends, live.