Whoer is an accessible starting point for checking a proxy for the first time. Its page combines IP, location, DNS and browser information with a prominent percentage. You can get a general sense of the environment without first learning how network databases work.
That design can also create a goal of its own: if someone else gets 100% and you get only 90%, does that mean your proxy is worse? It is easy to start changing languages and time zones, installing extensions and buying new addresses without knowing which changes affect the work you actually do.
I find Whoer convenient and clear, and useful for a quick overview of what the current browser presents to the outside world. Its best use is to follow the summary through to a specific problem, rather than treat the percentage as a ranking of proxy quality. To decide whether it deserves a permanent place in a toolkit, we also need to examine how it explains results, handles module states and places commercial recommendations alongside them.
An overview of the current environment saves time
Open Whoer's English page, and the exit IP, location, network information, proxy status and browser details appear together in one view. Compared with entering an arbitrary IP into a database lookup, this is closer to asking what this browser looks like right now.
That is a practical advantage. If the browser still shows the local exit IP after you connect a proxy, you can investigate the setup before spending time on whether the address is a native IP. If the region is correct but language or time information differs from what you expected, you can see that in one place, without switching between several websites.
What the browser currently shows and what the supplier sold are separate checks. Whoer sees the current request and some browser details. Those alone do not establish exclusive allocation, residential origin matching the order, or the same exit in other applications. It helps check the setup without completing the whole purchase assessment.
I would use it first to confirm the actual exit IP and obvious configuration differences, then add other tools according to the problem. That low barrier to entry is valuable for remote support, network changes and ordinary users. For complex faults, it is a starting point.
What does the anonymity percentage mean? Separate everyday language from the page's rules
“Anonymous” can mean many things in everyday language: a website cannot see the local public IP address, separate visits are difficult to link, an account identity is not recognized, or network activity does not pass through a service you do not want to use. Whoer's percentage can cover only the checks and rules it has selected.
A score of 100% therefore does not mean that all those goals have been achieved. Nor does 90% mean there is a 10% probability of exposing your identity. Unless a service explicitly explains what its model means and supplies validation evidence, an interface percentage should not be converted into a real-world risk probability.
The reason for a deduction matters more than the number. If it points to an unexpected exit IP, that deserves priority. If it reflects an explainable language difference, assess it in the context of the task. Two environments that both lose ten points may have problems of entirely different severity.
What would I expect from a tool that provides an overall score?
At a minimum, it should tell users which checks have run, which are still pending, what caused deductions and how to verify that a change worked. Listing “how to fix it” is not enough. It should also explain which risk the fix addresses and whether it could affect normal functionality.
Whoer's strength is making issues easy to notice. Its weakness is that users may accept the overall score first, then look for ways to restore every missing point. When reviewing it, I consider how that design influences behavior, as well as how much information the page contains.
For ordinary readers, I suggest first writing one sentence: “What kind of exposure am I concerned about right now?” If you cannot answer, avoid changing the environment just to improve a number. A tool should help define a problem, rather than encourage people to see every difference as a defect that must be removed.
When do differences between location, language and time zone need attention?
By putting network and browser information on the same page, Whoer makes relationships between regions easy to notice. The benefit is that unexpected configurations can become visible. The risk is that every difference can start to look suspicious.
A person working in a multilingual environment might use an English-language browser, for example. An overseas exit IP in another country does not automatically make that unusual. Travel, remote work, standardized corporate configurations and personal preferences can all produce reasonable differences.
There are three separate settings to understand:
- IP location: where the database places the exit.
- Browser language: which language you prefer websites to use.
- Device time: how the computer displays local time.
Each has its own purpose. Matching values do not rule out every other issue, and differences do not always need fixing. Check the effect on your work before changing everything to match a country.
Which differences would I fix first?
The first category is a clear conflict with the intended configuration. For example, you think the browser is using one proxy, but its actual exit IP belongs to another route. That affects both location and path assessment. The second is a configuration issue that disrupts normal work, such as an incorrect clock causing functions to fail. The third is environment consistency where the task has an explicit requirement and there is evidence that an adjustment is needed.
Without a practical requirement, avoid randomly changing every setting to raise the score. Each change can introduce problems with compatibility, stability or the ability to explain the configuration. Changing addresses can also alter the conditions being verified. Treating risk management as a permanent requirement to maintain a perfect score often creates pointless work.
I value Whoer's ability to bring differences together. The explanation should not end at “different from the IP country,” however. A site observing a difference has established that the difference exists. It cannot determine the reason on behalf of every business platform.
Proxy status and blacklists: the summary is an alert, while the source supports investigation
Whoer makes proxy alerts easy to notice in its overview. Request characteristics and proxy ports mentioned on the page are detection clues, not a guarantee that it can identify every proxy. I would use this field to decide what to investigate next: follow up on an alert, and still confirm the browser’s actual exit when none appears. This review did not validate each detection method.
If the status says no proxy was identified, that does not establish that the connection bypassed a proxy, or that the destination website cannot identify one. Whether a proxy is actually in use should be checked against the client configuration and exit IP. Whether it is identified depends on the detector's methods, coverage and timing.
The same applies to blacklists. During the page observation on October 21, 2026, the relevant status linked to a Spamhaus lookup. A traceable link is more useful than an unexplained overall score because users can investigate what the list covers and the particular records involved.
One list does not represent every reputation service, however. A “not listed” result cannot be rewritten as acceptance by every platform. A match also needs to be checked for timing, category and current impact. Some addresses may retain historical records after reassignment; past incidents should not all be attributed to the current user.
| Result observed | Initial interpretation | Further verification |
|---|---|---|
| Current exit IP differs from the expected one | The proxy setup or routing may differ from the intended configuration | Proxy scope, the current request and the client |
| No proxy identified | This check did not return the corresponding label | Actual exit IP and any other necessary signals |
| Blacklist alert | An external signal deserves investigation | Specific source, time, category and current impact |
| Location information differs | Data or configuration differs | First distinguish location sources from actual task requirements |
I think it works best as an alert at this stage. If a clear issue appears, follow it into more specific information. If nothing is wrong, continue normal work. There is no need to visit every other site just to collect matching results.
The detailed view is most useful when different observation methods help explain one another
Whoer's detailed area does more than repeat the homepage fields in a longer list. It also shows request headers, information read by scripts and system-related details. Those come from different observation methods. The distinction can help when investigating why a website still sees something different after you have changed a setting.
HTTP request headers are information the client sends with a request to a website, such as language preferences and a description of the client. JavaScript can read certain browser capabilities and environmental information while the page runs. These are different interfaces. A setting or extension that changes one output does not necessarily change the other.
Identify the source of a field before deciding that a configuration change failed
For example, the language displayed in the interface, the language preference in a request and language-related information read by a script may involve different configuration layers. When they differ, record the particular field, then investigate how the browser or relevant tool handles it. Saying only “I changed the language but it did not work” is too broad to help support staff locate the problem.
The same applies to User-Agent. It is the client's description of itself, rather than proof obtained by a website physically inspecting the device. Changing that text does not change every underlying graphics, protocol or system capability. A discrepancy between the text and another output also needs a specific explanation. One field alone is not enough to declare an environment falsified.
I think this is a part of Whoer's value that the percentage often overshadows: users can move from an overview to several different kinds of information. Retaining sources and the necessary fields can turn a broad complaint that detection results differ into a smaller, more tractable question. People who do not need detailed troubleshooting can skip this area for the time being rather than be put off by a long table.
Multiple time fields are useful, but a difference between UTC and local time is not a fault
The detailed area also lists information such as time zone, local time, system time and UTC. UTC is a common time reference, while local time is displayed according to the time zone. Different text in those fields is normal, and some regions also observe daylight saving time. Check how the offset relates to the actual settings, rather than requiring every time entry to look identical.
An inaccurate device clock can affect normal functionality and deserves attention. A correct clock displayed for a different region does not by itself indicate a leak or fraud. Network location and time zone settings can raise a question, but a difference alone cannot establish the nature of a problem.
Instead of judging professionalism by the number of fields, I would ask whether readers can tell where each field comes from, what a difference means and how to verify a change. Whoer supplies considerable material, but its explanations are not always detailed enough. It is more useful when approached with a defined question than as a page whose every value users must make consistent.
Why is fingerprint information worth examining without becoming a cause for alarm?
Whoer's extended area lists information such as User-Agent, request headers, screen details, language, time zone and feature states. Browser fingerprinting can be understood as a website combining these characteristics to distinguish or link environments. It is different from an IP address and from an individual cookie.
EFF's explanation of its Cover Your Tracks research describes studying identifiability by collecting browser configurations and comparing them with an observed sample. It also distinguishes tracker blocking from fingerprint characteristics. That is useful context for Whoer: hiding a network exit IP effectively does not mean other identifying information disappears with it.
Statistical conditions still matter. A characteristic that is rare within a sample of visits is not necessarily unique worldwide. Producing a signature does not establish that a particular platform used it to link accounts. Assessing a specific fingerprint risk requires knowing the comparison sample, timing, combination of features and how they are actually used.
Changing a proxy does not automatically remove every existing piece of identity information
If you are already logged in, the website already knows which account the visit is associated with. Cookies and other state may remain. The system and graphics characteristics a browser exposes do not all change because its address changes. The presence of these normal mechanisms should not all be interpreted as a proxy supplier's failure.
Likewise, deleting a field or randomly changing one fingerprint characteristic does not necessarily make the environment harder to link. Relationships between modules and whether changes are reasonable still need explanation. Whoer's overview can reveal characteristics, but it does not prove that a particular modification strategy will work.
I suggest defining the privacy or task objective first, then addressing the features that are actually relevant. If the need is simply stable access to an authorized service, there is no reason to randomize everything without evidence. If you are studying what the browser exposes, modules from tools such as BrowserLeaks can help inspect specific outputs.
Results and product promotions sit close together, and that affects the experience
Whoer's page also displays promotions for proxies, VPNs and browser-related products. Detection status, recommendations and purchasing links frequently appear together in one view. Fingerprinting explanations are closely associated with browser products as well.
Commercialization alone does not determine whether a finding is correct. It is also normal for a free tool to need funding. The relevant question is whether ordinary readers can clearly distinguish what the check actually observed, what the website recommends on that basis and what a product promises to solve.
People worried about privacy can easily assume an inevitable causal chain: seeing “exposure,” they infer that a serious problem has already occurred; seeing a product next to it, they assume buying it is a necessary fix. A review should not endorse that inference. It should distinguish specific evidence from marketing language.
I would establish the actual anomaly first. If the issue is only routing or DNS resolution, start with configuration. If the need is to manage several work environments, evaluate management tools. If nothing is wrong, using the free overview alone is also reasonable. Products should respond to a need, rather than an unexplained percentage creating one.
For everyday use, keep a stable record of the environment
For ongoing operations, knowing what an environment should normally look like may be more useful than reaching a perfect score once. When the exit IP, location, main browser details and DNS behavior are understandable, changes become easier to investigate.
Start by saving a completed baseline and noting the browser, scope of the proxy configuration and necessary fields. After replacing a resource or updating a client, compare the relevant items rather than changing every setting again. If an anomaly appears, the record can also show when it began, what changed and what it affected.
If you use PuraRoute's static residential resources, the resource list lets you check Exit IP, Location, validity period and notes. Associate those resource records with the corresponding work environment, then use Whoer to check the browser's actual exit IP. That has more management value than remembering a past anonymity percentage. Tasks that need the same exit IP over time can also use these records to track expiry and allocation.
Keeping those records shows where to start when the environment changes. A fixed, exclusive IP does not change the browser’s time zone, clear an existing login or guarantee a perfect Whoer score. I would record the normal setup and investigate changes, rather than buy new addresses repeatedly over a few points.
How can you tell whether to keep investigating or stop?
I would first address an actual exit IP that differs from expectations, an explicitly unwanted public network path, relevant list entries and persistent business faults. These point to identifiable problems with ways to investigate further.
Explainable language and time zone differences, or supplementary information with no practical impact, can be handled according to the task. Without evidence, “looks inconsistent” should not automatically become a reason to replace a proxy.
For modules that have not completed, record the result as unknown and repeat the check if necessary. Do not count it as a pass, but do not immediately assume the resource is faulty either. This intermediate state matters because real pages have network waits, script requirements and permission differences.
Use three situations to distinguish actions rather than merely compare scores
The following are hypothetical applications of the method, rather than proxy performance tests conducted for this review. First, if the score is good but the exit country differs from the order, prioritize delivery and routing checks. Second, if a small deduction comes from a reasonable multilingual configuration and the task is stable, keep the environment for now rather than change it blindly for a number. Third, if a result identifies a specific anomaly that persistently affects the work, investigate further through the relevant module and actual errors.
The three situations may produce different percentages, but the most reasonable next step depends on the facts. Keeping the overall score in its role as a summary lets Whoer narrow the investigation rather than turn every difference into additional work.
Where would I place Whoer alongside other tools?
Compared with IPinfo and Ping0, Whoer is closer to an overview of the current browser environment; the resource's network background is not its sole focus. Compared with BrowserLeaks, it is easier to start using, but raw candidates, protocols and module explanations are less concentrated. Compared with IPLeak, its summary is more prominent, while paths used by different applications still need separate verification.
I would recommend it to people who need a quick look at the exit IP, DNS and system overview. It also provides a common starting point for observations during remote support. For complex leak diagnosis, fingerprinting research or rigorous delivery acceptance, add more specific evidence.
My reservations are that the percentage can overshadow the explanation, commercial recommendations sit close to the results, and parts of the Chinese presentation need updating. Its value is in helping identify the next step, rather than making users believe that one perfect score ends all risk.
FAQ about Whoer
Does 100% on Whoer mean complete anonymity?
No. It covers only selected checks and rules. It does not prove that accounts, cookies, behavior and every network path are incapable of linking the user.
Does 90% mean a proxy is worse than one scoring 100%?
The percentage alone is not a basis for comparison. Look at the specific checks, whether modules have completed and the actual task. Some differences are reasonable; others need priority attention.
Must I change the language if it differs from the exit country?
Not necessarily. Multilingual use and work across regions are common. Decide according to the task and actual evidence, rather than making arbitrary environment changes for a score.
Does “no proxy detected” prove that a proxy is not being used?
No. A detection result is different from the actual connection path. Confirm it using the client configuration and exit IP.
If blacklist status is clear, will every platform accept the IP?
No. The specific source and its coverage matter. A no-match result cannot decide how other business services will respond.
Is it unusual for a browser fingerprint to remain unchanged after changing the IP?
Not necessarily. Browser and system characteristics are not determined by the proxy exit IP. Establish the problem you are trying to solve before investigating the relevant features.
Can blank fields on the page be treated as no risk?
No. Loading, script requirements and modules that have not run can all produce blanks. Retain the status rather than filling in a pass yourself.
