Where Does Test IQ Free Store Answers, and Can the Site See Your Result?

What does the published statement let you conclude?

“Answers stay in your browser” can be read as a bounded statement about where answers are kept, or as a broader promise that nobody else can see them. The readable Test IQ Free homepage supports the first reading as the publisher’s own description: it tells visitors that answers stay in the browser. It does not, by itself, establish the precise storage method, whether scoring happens locally, or whether answer or result values are sent elsewhere. So the responsible conclusion is limited: the publisher makes a browser-retention representation, but the accessible evidence does not independently verify a no-transmission guarantee. The homepage is meaningful evidence of what the publisher represents and may describe intended behavior; treating it as proof of the full data flow would go beyond what it says. (Test IQ Free homepage; accessed October 3, 2026.)

Those are separate questions because “in the browser” can describe a user-facing experience without specifying every step behind it. An answer could be held temporarily by the page, written to browser-managed storage, or handled through another arrangement. A result could be calculated from values already present in the page, or the page could communicate with a service. The homepage wording available for this review does not identify which mechanism is used. Nor does the accessible material establish the opposite—that answers or results are collected remotely. Neither transmission nor non-transmission is demonstrated here.

The evidence boundary matters. The homepage was readable during this review on October 3, 2026, but linked policy and methodology text was not readable in the research pass. No deployed code, storage inspection, or network capture was available. That means this is a finding about the public statement and the material accessible for this review, not a live technical audit. A readable, current explanation of data categories and processing, corroborated by the deployed implementation or a scoped observation of the test and results flow, could sharpen the conclusion. Its absence from this review is an access limit, not proof that such evidence does not exist.

Privacy and score meaning should not be collapsed. The displayed range is provisional, produced by an unvalidated conversion with no validated adult reference population; it is not a confidence interval or established comparison with a population. That limits what a person can conclude about their reasoning from the number. It does not make the answer pattern or displayed result inherently insensitive: a provisional estimate can still matter to the person taking the test. Measurement uncertainty answers “what does this score mean?”; data handling answers “who can access or retain these values?” One does not settle the other.

For a casual practice session, the publisher’s statement may be a useful part of a reader’s decision, provided the remaining uncertainty and current privacy information are acceptable to them. Someone who requires confidentiality as a condition has a different threshold: the available wording does not supply enough detail to treat that condition as verified. The conclusion here is deliberately narrower than a general safety judgment. It says what the accessible homepage represents, identifies what that representation leaves unspecified, and leaves site-specific transmission unresolved.

The word “answers” also needs to stay distinct from “result.” A completed test can involve selected responses, feedback about reasoning areas, and a displayed estimate. A statement about answer storage does not automatically specify whether those other values are calculated, displayed, retained, or transmitted in the same way. The available homepage wording is not granular enough to settle each category separately. That is why a reader asking whether the site can see the result cannot infer an answer solely from where the site says answers stay. A more precise explanation would say which values the statement covers and what happens to each; until then, the public representation should be read at its stated scope, not expanded to every output of the test.

Sources: Test IQ Free homepage

What could “in this browser” mean over time?

A browser can keep information for different lengths of time and within different boundaries. MDN’s “Web Storage API” describes two familiar possibilities: sessionStorage is separated by origin and tab and ordinarily ends when that tab closes; localStorage is separated by origin and persists across browser restarts. An origin is the site identity formed by its scheme, host, and port—for an ordinary visitor, think of it as a particular website address and service context. These are examples of browser-platform behavior, not evidence that Test IQ Free uses either API. A site can use other browser-managed storage or combine approaches, and the homepage wording does not name an implementation.

The difference affects what “later” might mean. With a session-bound copy, reloading the same open tab may leave state available, but closing that tab ordinarily ends the session. A persistent browser copy may survive a reload, tab closure, and browser restart. Either pattern can be scoped to the current browser profile: opening the same site in another profile can look like a fresh visit because that profile has its own storage area. A different device also has a separate local browser store unless some additional synchronization or account-based mechanism connects the experiences. The phrase “in this browser” alone does not tell a reader whether that connection exists.

Consider two explicitly hypothetical designs. In one, an unfinished test is held for the current tab only: it may resume after a reload in that tab, then disappear when the tab closes. In another, progress is saved persistently in that browser profile: it may remain after restarting the browser, yet not appear in a second profile or on a phone. A third design could combine local state with a remote copy. These illustrations show why the same visible “resume” behavior does not identify where state lives. A test that resumes after reopening may use persistent local storage, remote storage, or both; interface behavior alone cannot distinguish them.

Private browsing changes the expected lifetime of browser-held information, but exact behavior can vary by browser and settings. A private window may retain data while it remains open and clear some of that state when the private session ends; it should not be treated as a universal guarantee about every storage mechanism or about requests made during the session. Likewise, clearing site data can remove copies held by the browser for that site, but it cannot reach a separate copy on a server. Deleting browser history is also not necessarily the same action as clearing all site storage. The control acts on the local browser’s records within its scope.

MDN’s description of Web Storage helps explain the lifecycle options, not the particular lifecycle used by this test. Therefore, do not infer cross-device synchronization from a successful return to an unfinished test, and do not infer complete deletion from clearing local site data. Those actions can tell you something about the copy held in that browser, depending on browser behavior; they cannot alone establish whether another copy exists or was transmitted. This section concerns persistence and scope. It does not determine what information a network request may carry.

For someone using a shared device, the profile boundary has a practical consequence: persistent browser-held progress could remain available to another person using that same profile until it is removed or expires. A separate profile limits casual exposure through that browser’s ordinary storage separation, though it does not answer any separate questions about network handling. Conversely, using a private window can reduce the chance that a later user of the same profile sees persistent local state, while still leaving the person unable to infer from the window choice what happened during the session. These are conditional implications of browser storage patterns, not claims about this site’s observed behavior.

The narrow user inference is straightforward: the homepage phrase does not promise that progress follows you across devices, nor does it define how long a local copy lasts. If you need to remove browser-held state, use the browser’s site-data controls for the relevant site and profile; that addresses that local copy only. If you need to know whether a session ended every copy, browser controls alone cannot answer it. The exact implementation would need to be stated or observed; familiar storage names describe possibilities, not a site-specific result.

A visible result remaining on screen after completion would likewise tell little about its later lifetime: the page may still have the value in active memory even if no persistent save is made. Closing the tab ends that visible page session, but persistence beyond it depends on how state was kept. This is another reason not to equate a momentary display with a durable browser record.

Sources: Web Storage API - MDN

Can page code access a result that stays locally?

Yes, code that runs as part of the assessment page may be able to access values held by that page, even when those values never leave the device. The same-origin policy is the browser rule that generally separates one origin from another; an origin is defined by its scheme, host, and port. As the MDN guide “Same-origin policy” explains, scripts from an unrelated origin are generally blocked from directly reading another origin’s page data and storage. That separation is a real browser protection. It does not mean that a page is sealed off from its own application code. A result can therefore be browser-accessible to the page while remaining unknown to a separate website that has no access to the assessment page’s origin.

This distinction is about capability, not proof of an action. OWASP’s “HTML5 Security Cheat Sheet” cautions that JavaScript running in the same origin can access localStorage and that browser storage should not be treated as confidential from that code. If a page’s own scripts can read a stored answer, the page can potentially use it in the interface or in application logic. That statement does not allege that any particular script at Test IQ Free reads answers, behaves improperly, or sends them elsewhere. No deployed-code inspection or live observation is available here to establish what the site’s scripts do. The general browser model describes what may be possible in a page context, not which possibility a publisher chose.

Three phrases help keep the question precise. “Browser-accessible” means a value is present in a place the page or its code can reach under the browser’s rules. “Locally calculated” means the browser performs the computation using values available there and can render its result without asking a remote service to calculate it. “Remotely received” means a server or other recipient actually gets the relevant value through a request or another channel. These conditions can overlap, but none follows automatically from the previous one: a locally accessible value need not be calculated locally, and local calculation does not establish whether a copy is later sent. A visible result only shows that some part of the application can render it; it does not reveal the full route by which the result was produced or handled.

For illustration only, imagine one test page that stores selections in its browser context, calculates a display there, and makes no request containing those selections or the derived result. The page must have access to the values it uses to calculate and show the display, while an unrelated site remains blocked from directly reading that origin’s storage. Now imagine a different design in which the page sends selections to a scoring endpoint and receives a result. The endpoint in that hypothetical receives the submitted values because the application sends them; that is a separate data-flow choice, not a consequence of local storage being readable by page code. Neither design is a claim about Test IQ Free’s implementation.

Origin isolation also should not be read as a blanket privacy guarantee for everything displayed in a page. It sets boundaries between origins; it does not prevent the application from using values within its own context. Conversely, the fact that application code may access a value is not proof that the value is transmitted, retained remotely, or exposed to an unrelated site. Those conclusions require evidence about actual application behavior. The MDN description of the same-origin policy supports the boundary, while OWASP’s storage guidance explains why local browser storage is not a secret vault from same-origin code; neither source observes this test’s code or requests.

For a reader, the practical distinction is modest but important: “kept locally” and “known only to me” are not equivalent statements. If an answer or result is available to the assessment page, its own code may be able to work with it. That fact alone does not answer whether a server receives it. A page can possess enough information to render a result while no answer payload is sent; another application can send values for remote scoring. Determining which description fits a specific live test requires site-specific evidence, rather than assuming either transmission or non-transmission from the browser’s access rules.

The origin rule should therefore be understood as a boundary around direct cross-site access, not a measurement of confidentiality inside the application. An unrelated page cannot ordinarily reach into another origin’s storage simply because both are open in the same browser. At the same time, code operating as part of the assessment page belongs to the context that handles its interface and data. This distinction helps avoid two opposite errors: treating browser storage as inaccessible to all software, or treating potential page-level access as evidence of a remote disclosure. The browser standard defines the separation; the site’s implementation determines what the page actually does with accessible values.

Sources: Same-origin policy - MDN; HTML5 Security Cheat Sheet - OWASP

What might routine requests reveal without sending answers?

A browser can contact a server during a visit without sending the test taker’s answer selections in those requests. Loading a page and retrieving its ordinary resources involve network requests; a server handling them may learn that a browser requested a particular page or resource and when the request arrived. The request can also include ordinary context such as a URL path, browser headers, or cookies that match that request. These categories describe common web traffic at a general level. They are not a list of observed Test IQ Free endpoints, fields, cookies, or logging practices: no site-specific network capture was available for this review.

MDN’s “Using HTTP cookies” explains an important difference between cookies and browser storage. A matching cookie may be attached by the browser to a corresponding request, subject to its attributes and the request context. By contrast, a value kept in Web Storage is client-side and is not automatically attached to every request. A cookie accompanying a page or resource request may help a service associate activity with a browser or session, depending on the setup. Its presence would not, by itself, show that the request also contains quiz answers or a calculated IQ range. Association context and assessment content are different categories of information.

The request’s address and timing can also describe the visit without describing a response. For example, an illustrative request to load a test page could reveal that the page was requested at a particular time; the request might include browser-level headers and any matching cookie. That example does not imply a specific tracker, logging system, or endpoint is present on this site. A path can identify a resource or page while leaving the selected options out of the request body. Conversely, application traffic can include fields beyond what is apparent from a page address. The question of what was sent cannot be resolved merely by observing that the browser made contact with a server.

This is why “the browser contacted a server” is a narrower statement than “the server received my answers.” The first concerns the existence of a request and potentially its ordinary context; the second concerns the request’s content or another transmission channel. A page may request images, scripts, styles, or other resources as part of normal loading, and those requests can occur while answers remain in the browser. Some web requests do carry values a person entered, so ordinary metadata should not be used to rule out a payload either. The actual content and destination of relevant requests are what distinguish these possibilities.

The distinction also matters for derived information. A server could receive a page request without receiving a displayed score, or an application could send a result while leaving raw selections out of that particular request. A path, timestamp, or matching cookie does not establish which of those cases occurred. Nor does a lack of visible answer words in a URL prove that no answer data were sent by another part of the request: request content can have more than one component. These are general distinctions in interpreting web traffic, not findings about any specific request made by Test IQ Free.

For data minimization, the useful question is therefore specific: what does routine visit logging need to record, and what assessment values, if any, are included in application requests? A minimal page request might be useful to serve the page or understand that a resource was requested without containing answers or a result. A request that includes answer selections or a derived range carries different information and should be described as such. This framing neither assumes a site sends test content nor treats all request metadata as harmless; it separates the evidence a reader would need to know which kind of information a server received.

Cookies deserve careful wording for the same reason. They can ride along with matching requests and may support continuity or association, while the answer choices themselves are separate values that would need to be included or otherwise made available to the recipient. Seeing that a browser sent a cookie would establish only that request context, not that the cookie contains the test responses. Seeing a request go to a server likewise establishes a connection, not its full payload. MDN’s documentation supports this general distinction, but does not enumerate this site’s traffic. A site-specific answer would require the actual requests and their contents across the relevant test and results flow.

Sources: Using HTTP cookies - MDN

What changes when outside scripts are present?

An outside script can change who has technical opportunity to handle activity in an assessment page, but its presence alone does not show that a provider receives answers or a score. The important distinction is how the code is integrated and what information the page makes available to it. OWASP’s “Third Party JavaScript Management Cheat Sheet” treats externally supplied JavaScript as a trust and governance concern because code brought into a page can affect the page’s behavior. That is a reason to ask about provenance and access, not evidence that Test IQ Free loads any particular outside script or shares test values.

A script element that loads JavaScript into a page runs as part of that page’s execution context. MDN’s “Web Storage API - MDN” describes this embedding model: a script included by a site is not automatically confined to a separate mini-page merely because its file came from another host. If the assessment page exposes values or events to such code, or if the integration grants access to them, the script may be capable of working with what the page makes available. Whether it actually observes a completion event, answer selection, or result depends on the implementation and available data; code provenance alone does not establish those actions.

An iframe is a different arrangement: it displays a separate document in a nested browsing context, and browser origin boundaries generally limit direct script access across origins. MDN’s “Same-origin policy - MDN” explains that the boundary depends on the origins involved, while permitting some cross-origin embedding and communication arrangements. A separate origin therefore changes the default access boundary, but does not prove that no information is exchanged. A host page could send information into an embedded component or receive information through a designed interface. For this article’s question, the useful distinction is simply that directly included code joins the embedding page’s context, whereas an iframe has its own document and may have a different origin boundary.

The possible data handled also come in different levels. A provider might receive only a resource request or a coarse event such as a page view or test completion. That event metadata is not the same as a set of selected answers, domain feedback, or the estimated range. A more detailed integration could make additional fields available, or code might initiate a request with values it can access; either would depend on how the page is built and configured. Consequently, “a provider’s script loaded” establishes that a resource was requested or code was made available, while “the provider received quiz responses” requires evidence that the responses or an equivalent payload reached a destination.

The same separation applies to a result. If a page reports a completion event without including the displayed range, the destination may learn that a test flow reached that event without receiving the score value. If the range is included in a request, that is a different disclosure. Those are hypothetical examples of how event design can differ; neither describes observed traffic on this publication. OWASP’s guidance supports reviewing the trust placed in third-party code, but it does not establish what any deployment sends. Counting script hosts without inspecting event fields and request destinations would therefore leave the central question open.

A site-specific script inventory would show which external and first-party scripts are present in the inspected build and where their code is sourced. Observed requests during a defined test and results flow could show which destinations were contacted and, where visible to the inspection, what event or result fields were sent. Comparing those records with the page integration would help distinguish a loaded library from a recipient of assessment data. The inventory has a time boundary: scripts and configuration can change between releases, and different pages, consent settings, or user paths may load different code. A snapshot describes the inspected version and flow, not every future visit.

The useful control questions are concrete: which scripts run on the assessment and results pages; what events and fields are passed to each integration; and are raw answer choices, domain feedback, or the estimated range available or transmitted? Narrowly configured third-party resources may serve a limited function without ever receiving answer values, so the mere presence of outside code is not proof of collection. Conversely, an assurance about answers would be clearer if it specified whether it covers event metadata as well as answer and result fields. No script inventory or live destination observation is part of the evidence available for this article, so these questions define what would resolve the issue rather than assert a site-specific finding.

Sources: Web Storage API - MDN; Same-origin policy - MDN; Third Party JavaScript Management Cheat Sheet - OWASP

Is an IQ result identifying information without a name?

No name does not settle whether a set of answers or a result can be linked to a person. The practical question is what other information accompanies it, who can access that information, and whether the pieces can reasonably be connected. The “General Data Protection Regulation, Article 4” uses the idea of an identified or identifiable natural person and mentions identifiers and factors relevant to identity. That wording makes context central: removing a name may reduce direct identification, but it does not by itself prove anonymity; equally, a value without a name is not automatically enough to identify anyone.

It helps to distinguish what the data describe. Raw item choices record responses to particular questions. Domain feedback summarizes performance across a class of reasoning tasks. A displayed estimated range is a derived summary rather than the response pattern itself. A completion event may communicate only that someone reached a point in the test flow. These forms can have different detail and different uses, so a data-minimization question asks whether each category is needed for a stated purpose and whether a less detailed form would suffice. This distinction does not imply that any of these values are collected, stored, or sent by this product.

Consider a hypothetical example: an isolated range with no account, stable identifier, or surrounding visit record may be difficult to associate with a particular person. The same range attached to a signed-in account or a persistent identifier could be more readily linked to that account’s user. A sequence of item choices might also be more distinctive than a broad completion event, depending on context and available comparison information. These examples illustrate how linkage can change the question; they do not claim that Test IQ Free uses accounts, stable identifiers, or such event records. They also do not show that a particular value identifies a person in practice.

The information can become more linkable through combination rather than through a name appearing in the result field itself. A timestamp, session reference, or account record could connect a value to other records if a system actually holds and uses those connections. The presence of one of these elements would still need to be assessed in context: a random session token that expires and cannot be connected to another record differs from an identifier tied to an account. Article 4 gives a legal framing for identifiability, but the cited definition alone cannot establish which links exist, who controls them, or whether a specific dataset is identifiable.

Less detailed information can still say something about a person’s activity. A completion event might reveal interest in taking a reasoning test even if it contains no answers or range; a domain summary conveys more about areas of performance; raw responses preserve still greater detail about how someone answered. This is a comparison of information content, not a claim that every additional detail necessarily identifies someone. Context and linkage matter. For a service deciding what to handle, the disciplined question is whether it needs item-level data, a domain summary, an overall range, or merely a completion signal for the function at issue.

The displayed IQ range is a provisional estimate from an unvalidated conversion with no validated adult reference population; that qualification concerns measurement interpretation, not whether the value could be linked to a person. A weak or uncertain measurement can still be sensitive to the person who receives it or to someone who associates it with an individual. Conversely, a technically precise value would not identify a person solely by being precise. Measurement quality and identifiability are separate dimensions, so neither should be used as a shortcut for deciding the other.

For a reader, the sound conclusion is bounded: removing a name reduces one direct route to identification, but anonymity depends on the surrounding data and available links. A score in isolation may not identify anyone, and Article 4 does not classify this site’s data without facts about context and linkage. Raw answers, domain feedback, a range, and a completion event warrant separate descriptions because they convey different information. Nothing in that distinction establishes what the site collects or whether a specific result is personal data; it explains why a privacy answer needs to say which data category is under discussion and what context is considered.

Sources: General Data Protection Regulation, Article 4

What evidence would answer the site-specific question?

Different parts of the question require different evidence. A privacy statement records what the publisher declares; it cannot by itself show which browser API the current site uses or what a live test sends. For this review, the accessible material was the readable Test IQ Free homepage. The linked policy text was not readable, and no repository or deployed application code, browser storage inspection, or network capture was available. The homepage is therefore evidence of the publisher’s stated position, not an independent verification of the complete data flow. This access boundary does not show that further documentation or technical evidence does not exist.

To verify where unfinished answers persist, the relevant comparison is between the code matching the deployed build and the browser state during a defined test flow. The code can show which storage mechanism the application calls and when it writes, reads, or clears values; an observation of browser storage can confirm what appeared in that browser profile and how it changed across the tested actions. The Web Storage API - MDN describes possible browser mechanisms and their lifetimes, but its general documentation cannot identify which one this test uses. A storage snapshot alone also has limits: it may miss in-memory values, another storage mechanism, state created only on a different page, or server-side copies. Code and observed state answer related, not identical, questions.

Scoring location calls for tracing how the displayed result is produced. Code review can identify whether answer values are evaluated in the browser or passed to a scoring service; a browser and network trace can show whether the observed flow made a request associated with scoring and what destination and fields were visible to the capture. Looking at the result page alone is insufficient to locate the calculation: a locally rendered range could follow a remote calculation, and a browser-calculated range could still be sent afterward. These are ways to distinguish implementations, not descriptions of Test IQ Free. The Test IQ Free homepage says answers stay in the browser, but the wording available here does not settle where scoring occurs or whether a derived range is transmitted.

To determine whether answers or a result reach a recipient, capture the whole relevant path—from starting the test through completion and viewing results—and record destinations and request contents where observable. The Using HTTP cookies - MDN distinguishes cookies that accompany matching requests from Web Storage values that are not automatically attached; that general distinction cannot replace inspection of this application's actual requests. A request without a visible answer field may still carry encoded or transformed content, so interpretation should be tied to the payload and the code that constructs it. With encrypted transport, an observer between the browser and recipient generally cannot read the protected contents, while the receiving endpoint necessarily handles what it is sent. A capture at the browser can inspect the outgoing request before encryption; it says only what occurred in that captured flow.

A useful trace also needs a defined start and finish. If it stops when the final question is answered, it may omit requests made when the result page opens; if it begins only at the result page, it cannot show whether earlier answers were sent during the test. The record should therefore identify the browser, build or visit date, relevant settings, and user-visible steps covered. This makes the conclusion reproducible in scope: an observer can say what destinations and fields appeared on that path, rather than generalizing from a single request or an incomplete session. Where a field is not readable in the capture, its absence from view should not be reported as proof that no value was sent by another mechanism.

Evidence should be reported at the level of the question it actually resolves. Seeing a value in browser storage supports a statement about that profile at that moment; it does not establish that the same value was never copied elsewhere. Finding a scoring request supports a statement about that request and recipient, but not automatically about every answer or later retention. Conversely, finding no answer payload in a captured path can narrow the account of that path, provided the capture includes the relevant requests and the code path is understood. This proposition-by-proposition reporting avoids turning one technical observation into a blanket privacy verdict.

Retention and deletion need both a statement of declared practice and evidence about the systems that implement it. Readable policy text can describe categories, retention periods, and deletion routes; operational records or server-side configuration would be needed to establish what happens to remote copies and whether a deletion request reaches them. Browser controls can show what a user can clear from the tested profile, but that cannot verify deletion from a server or a provider’s systems. Each evidence type has a coverage boundary: source code may not match the active deployment; a trace covers a particular version, browser, settings, and path; and a policy describes a commitment rather than proving execution. Matching code, a scoped trace, and readable policy complement one another. A well-scoped capture plus matching code review could support a stronger statement about that tested flow, without establishing every deployment or later retention practice.

Sources: Test IQ Free homepage; Web Storage API - MDN; Same-origin policy - MDN; Using HTTP cookies - MDN

What should a privacy explanation say clearly?

A useful notice names the information it is talking about. “Answers” could mean raw choices for individual questions, while a domain summary and the displayed estimated range are derived outputs; a completion event is another, less detailed category. A reader should be able to tell whether a statement covers one of these categories or all of them. This precision matters because a narrow sentence about answer storage does not automatically describe every result or event. Naming categories does not require publishing test questions, scoring keys, or other proprietary assessment material.

The notice can then say where each category is processed and whether it leaves the browser. For example, “answer choices remain in this browser during the session” makes a bounded claim about location and time. “Nothing is transmitted” is much broader: a reader may reasonably understand it to include answers, derived results, and other data generated during the visit. If a service sends only a completion event or routine request context, that is still different from sending item responses or an estimated range, and the explanation should identify the distinction rather than leave “data” undefined. These examples illustrate clear wording; they do not describe observed Test IQ Free behavior.

Recipients and duration complete the picture. Where information is sent, a notice should identify the recipient by role and explain which category it receives, rather than implying that every provider receives everything or that no provider receives anything. It should distinguish how long a browser-held copy persists from the retention period for any server-side copy. A deletion instruction should name the copy and the action that affects it: clearing site data in a browser, for instance, is intelligible as a local-device action, while a request to the service concerns a different system. Plainly separating those actions helps readers avoid treating one successful deletion as proof that every copy is gone.

A reader should not have to infer the boundary from technical labels alone. “Stored locally” can describe a location without explaining whether the page can use the value, whether a copy is later sent, or how long it remains. Likewise, “deleted” is clearer when the notice names who can initiate deletion, which storage location is affected, and whether the action covers backups or copies held by recipients. If the service cannot make a claim about a category or system, stating that limit is more informative than using an unqualified promise. The point is not to make every notice long; it is to let a person match the assurance to the decision they are making.

A compact explanation could use separate sentences for each boundary: what the browser keeps and for how long; what, if anything, is sent and to whom; and what action removes local versus remote copies. If a category is not processed in a particular way, the statement can say so specifically. If duration varies by storage type, it can distinguish the session or device copy from a service-held copy instead of compressing both into “temporary.” Such phrasing reduces ambiguity because the reader can see which fact answers which question without needing to know the name of a browser API or reconstruct the system from technical documentation. It also avoids implying that local access is equivalent to confidentiality or that a deletion control reaches every copy.

These are communication criteria, not a finding that the current privacy notice is deficient. The linked policy text was not readable in this research pass, so no judgment about its full wording is available. A concise notice can be useful when its scope is clear; additional detail becomes important when a broad assurance might otherwise be read to cover more categories, recipients, or copies than it actually addresses.

How should you decide whether to take the free test?

For a casual reasoning session, you can decide based on whether the publisher’s current privacy information and the remaining uncertainty feel acceptable for that use. The homepage says free-test answers stay in the browser, but the accessible material does not independently establish the storage mechanism, where scoring occurs, or whether answers or the result are transmitted. If that bounded statement is enough for open practice, read the current terms, use a device and browser profile under your control, and proceed only if you are comfortable with what they say and what remains unspecified. Waiting is also a reasonable choice; it says nothing about your reasoning ability.

The free /test option is an original adaptive 50-question test covering pattern reasoning, number patterns, and spatial reasoning. Its displayed range is provisional: it comes from an unvalidated conversion without a validated adult reference population. Treat the activity as practice and the result accordingly, rather than using it to make a consequential decision. The optional $9 report adds explanation and a practice plan, not validity; paying does not resolve the privacy question or make the estimate more established.

If confidentiality is a condition—because the answers or result would be sensitive in your circumstances, or because you do not accept possible linkage—defer before entering responses. Ask the publisher for a specific account of what happens to raw answers and derived results, where each is processed, whether either leaves the browser, and how local and remote copies can be deleted. A general assurance about answers may be reassuring to one reader yet leave another's essential question unanswered. The appropriate threshold depends on the consequence you attach to that uncertainty, not on a universal rule that every visitor must either trust or reject the service. Be precise about the question you need answered: whether the statement covers only unfinished responses, completed responses, the displayed estimate, or all three. If you receive no clear answer on the category that matters to you, you can keep the same boundary and decline to start.

You can clear site data from the browser profile or device afterward if you want to remove browser-held state. Think of that as device housekeeping: it does not establish that a remote copy never existed or has been deleted. If a clear local reset matters, do it through the browser's site-data controls and understand that it may also remove saved progress. That action can address a copy kept by the browser; it cannot answer a separate question about processing or retention elsewhere.

So the practical choice has two paths. For low-stakes practice, proceed only after the current privacy information fits your tolerance for the unresolved details, and interpret the estimated range as provisional. For a strong confidentiality requirement, get a concrete answer first and skip the test unless that answer meets your condition. You do not need to buy a report to make either choice. If you simply want original reasoning questions and accept the stated uncertainty, /test is the free route; if the uncertainty itself is unacceptable, waiting preserves that boundary without requiring a judgment about the site's actual data handling.

Where does Test IQ Free store my answers, and can the site see my result?

The publisher says answers to the free test stay in the browser. The accessible homepage supports that as the publisher’s stated position, but it does not independently settle which storage mechanism is used, where scoring happens, or whether answers or the resulting range are transmitted. That leaves a bounded expectation, not a complete account of the data path. For a low-stakes practice session, read the current privacy information and use /test only if its terms and the remaining uncertainty suit you. If confidentiality is essential, ask the publisher to clarify answer and result processing and deletion before responding. The displayed range is provisional, based on an unvalidated conversion without a validated adult reference population, so it should not guide a high-stakes decision. A reader may reasonably find the publisher’s statement sufficient for open practice; another may reasonably wait. The sensible next step turns on what possible uncertainty would mean in your situation. Clearing browser data afterward can remove state held in that profile, but it cannot demonstrate deletion of a remote copy. This is why a specific clarification matters when privacy is a requirement; for ordinary practice, the decision can remain proportionate to the uncertainty you are willing to accept.

Sources: Test IQ Free homepage

Questions readers ask