DoHSpeedTest: measuring DNS over HTTPS resolvers from the browser

What the tool does, and the one design decision that defines it

The DNS Speed Test is a web application, hosted at dnsspeedtest.online, that identifies the fastest DNS server for your location by evaluating servers in real time from your browser.

The README puts the design decision up front. The tool performs its DNS queries directly from the browser to various DoH-capable DNS servers, bypassing traditional server-side resolution processes. Everything else follows from that.

The feature list is short. Real-time DNS testing pinpoints the fastest DNS server based on real-time data for your location. Customizable tests let you add or remove the websites used to trigger lookups. Detailed analytics give you min, median and max response times. There is interactive data visualisation with charts and graphs. The design adapts across different devices. And it is free with full access to all features and no cost.

The installation is genuinely trivial, which tells you what kind of artifact this is. You clone the repository and open index.html in a browser:

1. Clone the repository: `git clone https://github.com/BrainicHQ/DoHSpeedTest.git`
2. Open `index.html` in your browser to initiate the testing.

There is no build step, no package manager, no server component and no dependency install. The repository top level is index.html and script.js with a favicon directory, plus robots.txt, sitemap.xml and a loading.gif, and a tests directory. The primary language is recorded as JavaScript and the licence is GPL-3.0.

The last push was on 2026-10-07, there are no GitHub releases, and the tool is at the stage where the code is small enough to read in full.

Why client-side DoH changes the measurement

The technical insights section explains the client-side approach with four arguments, and they are worth taking one at a time because each one has a flip side.

Enhanced privacy and security is the first. Unlike typical DNS queries, the client-side DoH requests are encrypted, protecting them from interception and tampering. The usual DNS query to your configured resolver is plaintext on the local network, so this is a real difference, though it is worth remembering that the tool only demonstrates the encryption rather than making your whole browsing encrypted.

Real-world accuracy is the second and the most useful argument. By executing from the user's local environment, the test gives a more accurate assessment of DNS server performance from the user's perspective. This is the key difference from a server-side speed test, and it is a genuine improvement: the path from you to a resolver in Frankfurt is not the path from a data centre in Virginia to the same resolver, and the number that matters for you is the first one.

Dynamic request handling is the third, and this is the part that has a practical consequence. The tool is capable of both POST and GET requests, which means it can interact with a broader range of DNS servers, including those with strict CORS policies.

That last clause is the one to hold on to. CORS is the browser's rule about which origins a server will talk to, and a DoH resolver that a native client can reach may still refuse requests coming from a web page origin. A resolver with strict CORS policies needs the POST form to work, and a resolver that refuses cross-origin requests entirely will not work in the browser at all, however fast it is. The tool's list of resolvers and the results you get therefore depend on which origins those resolvers are willing to serve, which is a property of the resolvers rather than of your connection.

Reduced latency is the fourth argument. The client-side approach eliminates potential server-side processing delays, offering faster, more direct speed assessments. That is true of the measurement path, and it is the reason the numbers reflect the local route rather than a round trip through a testing server.

Reading the results, and what min, median and max tell you

The analytics are described as giving deep insights with min, median and max response times, and the customisable test list lets you add or remove the websites used to trigger lookups.

That combination is sensible, because a single DNS server's latency is not one number. A resolver can have a good typical time and an occasional bad one, and the min tells you the best case the resolver ever managed from your connection, the median tells you the typical case, and the max tells you the worst case you hit. If you are choosing a resolver for an interactive application, the median and the tail matter more than the min, and a tool that reports only the average hides the difference between those.

The customisable website list exists because different resolvers behave differently depending on what you ask them for. A cache hit for a popular domain and a cache miss for a rare one take different paths, and the same resolver can be quick on one and slow on the other. Being able to choose the names being resolved makes the comparison reflect the workload you actually have.

The visualisation is described as interactive, with charts and graphs for clear, engaging data representation, and the design adapts across different devices. That combination is a browser tool decision: the results are drawn in the page rather than printed, and the page has to work on a phone as well as a desktop because the most likely user is on whatever device they noticed a slow page load on.

The one number to be careful about is any single figure quoted as the resolver's speed. The tool measures the round trip to the resolver over your network at that moment, so it is a measurement of a path rather than of a server, and it will differ between your home connection, your office connection and a phone on a mobile network.

The disclaimer, and what it leaves out

The README ends with a disclaimer, and it is a single sentence: test results reflect your current network environment and are meant as a guide for choosing DNS servers.

That is accurate and understated. It says three things, of which the first is the important one. The results are a property of your current network environment, so they are not a benchmark of the resolver in general. The second is that the purpose is guidance for choosing, not a verdict. And the implicit third is that the conditions can change, so a result from this morning is not a result for tonight.

What the disclaimer does not mention is worth listing, since these are the places where a user can be misled by a chart.

The measurement is DNS resolution only. The tool does not measure page load time, throughput or the behaviour of anything except name resolution, so a resolver that resolves fast and a resolver that resolves fast but is subject to a bad ISP's interference will produce the same chart.

The CORS constraint sits behind the results. A resolver that will not serve a browser origin cannot be measured this way, so the fastest resolver on the list may be absent from the results, and one that is present but slow may be slow for policy reasons rather than performance reasons.

Cache state matters. A resolver with your names already cached will look fast, and a cold one will not, so the first lookup in a run is not comparable with the ones after it. This is exactly what the customisable website list lets you control, and it is the reason the min, median and max breakdown is provided rather than a single number.

None of this makes the tool wrong. It makes it a measurement of one specific thing, taken from one specific vantage point, at one specific moment, which is the right thing to want when you are deciding which resolver to configure and the wrong thing to treat as a general performance rating of the resolver itself.

The project itself, and what the repository contains

The project is maintained by BrainicHQ, and the README credits Silviu Stroe as creator and project maintainer. The topic list of the repository names no specific technologies beyond the web, and the primary language is JavaScript, which matches a two-file implementation.

The repository top level is worth reading as a description of the scope. There is index.html and script.js, a favicon directory, a loading.gif for the waiting state, robots.txt and sitemap.xml for the hosted deployment, and a tests directory. There is a .github directory and a .gitignore.

Two of those files are interesting. The presence of an llms.txt at the root is a convention for publishing a machine-readable summary of a site, and it means the hosted tool is set up to be described to automated clients rather than only to people. And a tests directory alongside a single script file suggests the measurement logic is separated from the page, which is what you would want to be able to test the timing behaviour without a browser.

The hosted instance at dnsspeedtest.online is the primary way to use it, and the local index.html route is the way to run it without the network round trip to somebody's server, which is the more private of the two and the one that matches the tool's own philosophy about client-side execution.

For support, the README offers a Buy me a coffee link with the note that your support fuels ongoing improvements and tool accessibility. Issues and feature requests go through the repository's issues page, and the contributing section is a one-liner welcoming contributions to enhance internet speed and security.

The licence is the GNU General Public License v3.0, which is worth knowing if you intend to fork the tool and host your own version, since the copyleft terms apply to a modified distribution. The last push was on 2026-10-07, so the project is being worked on, even though it has no GitHub releases and no version tags to track.

Editorial conclusion

Adopt DoHSpeedTest if you want a quick, privacy preserving way to compare a handful of DoH resolvers from your own connection, since running the queries client side means the result reflects your path rather than a server's. Do not treat the output as a network quality measurement, because the test times DNS resolution and nothing else, and note that a resolver which blocks or rate limits browser origins will look slow for reasons that have nothing to do with its speed. Before you switch your resolver, re-run the test from the connection you actually care about, and read the CORS caveat in the technical notes, because a resolver that refuses cross-origin requests will fail or look slow in the tool.

Frequently asked questions

Official sources

1. BrainicHQ/DoHSpeedTest on GitHub
2. Issues
3. License: GPL-3.0
4. README