Check WiFi channel overlap for 2.4 GHz channels
This Wi-Fi channel overlap checker compares any two valid 2.4 GHz channel numbers and shows whether their nominal 20 MHz frequency ranges intersect.
Run — free
It calculates the standard center frequency for each channel, displays both lower and upper range boundaries, and reports the width of their shared spectrum. The result is useful when planning access points, investigating interference, or explaining why nearby channel numbers are not necessarily independent. Channels outside the standard range of 1 through 14 are rejected clearly.
What the overlap result means
A 2.4 GHz Wi-Fi channel number identifies a center frequency, not an isolated slice of spectrum with empty space around it. With the standard 20 MHz width used by this checker, the nominal range extends 10 MHz below and 10 MHz above that center. Two channels overlap when those open frequency spans share a positive width. The result therefore depends on frequency separation rather than simply on whether the channel numbers differ. For example, channels separated by only one or two channel positions share much of their nominal spectrum and can interfere strongly when nearby networks transmit at the same time. The response includes the center frequency and calculated range for each input, a Boolean overlap result, and the shared width in megahertz. If the two ranges only meet at one boundary, the shared width is zero and the result is non-overlapping. This explicit rule prevents a single mathematical endpoint from being mistaken for shared usable bandwidth.
How channel frequencies are calculated
For channels 1 through 13, center frequencies begin at 2412 MHz and rise in 5 MHz steps, ending at 2472 MHz for channel 13. Channel 14 is the special case: its center is 2484 MHz rather than the next ordinary 5 MHz step. The checker applies these standard centers and places a nominal 20 MHz range around each one. It then finds the lower of the two upper boundaries and subtracts the higher of the two lower boundaries. A positive result is the overlap width; zero means there is no shared interval. This model is intentionally focused and deterministic. It does not estimate signal strength, distance, walls, transmitter power, regulatory permission, adjacent-channel rejection, spectral masks, or the wider occupied bandwidth of 40 MHz operation. Those factors matter in a complete radio survey, but they are different questions. Here, the answer strictly describes nominal frequency-range intersection for two 20 MHz 2.4 GHz channels.
Using the answer in network planning
Use this result as a quick screening step when assigning channels to access points or reviewing a crowded scan. A large reported overlap indicates that the two selections occupy much of the same nominal spectrum, so simultaneous nearby transmissions are more likely to contend or create adjacent-channel interference. A zero-width result says only that the nominal 20 MHz ranges do not overlap under this calculation; it does not guarantee a clean connection. Real performance also depends on how many devices are active, signal levels, physical separation, obstructions, equipment quality, and local interference from non-Wi-Fi sources. Channel 14 also requires special care because availability and permitted operating modes vary by jurisdiction and equipment. Validate local regulatory requirements before deployment. For repeatable automation, send the two integer channel fields through the API for $0.002 per request. The same deterministic arithmetic can support configuration checks, inventory audits, and documentation without requiring a live scan or access to either wireless network.
What you can do with it
Plan neighboring access points
Compare proposed 2.4 GHz channel assignments before deployment and flag pairs whose nominal 20 MHz ranges share spectrum.
Explain interference findings
Turn two channel numbers into visible center frequencies, boundaries, and shared bandwidth for a support report or troubleshooting note.
Audit wireless configurations
Run deterministic checks across documented access-point pairs and identify channel selections that deserve closer radio analysis.
FAQ
Which channel numbers are accepted?
Both inputs must be integers from 1 through 14. Any value outside that range is rejected as invalid input.
What channel width does the checker use?
It uses a standard nominal width of 20 MHz, represented as 10 MHz below and above each channel's center frequency.
Do ranges that only touch count as overlapping?
No. If the ranges meet at exactly one boundary, their shared width is zero and the checker reports no overlap.
Why is channel 14 handled differently?
Channel 14 has a standard center frequency of 2484 MHz, which does not follow the regular 5 MHz sequence used for channels 1 through 13.
Does no overlap guarantee no interference?
No. The result covers nominal frequency ranges only. Signal strength, spectral leakage, other transmitters, hardware, and the physical environment can still affect performance.
Can this check 40 MHz channels?
No. This capability is intentionally limited to standard 20 MHz channel width in the 2.4 GHz band.
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/misc2/wifi-channel-overlap-check \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"channel_a":1,"channel_b":6}'const res = await fetch("https://api.kit.forhosting.com/misc2/wifi-channel-overlap-check", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"channel_a": 1,
"channel_b": 6
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/misc2/wifi-channel-overlap-check",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"channel_a": 1,
"channel_b": 6
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/misc2/wifi-channel-overlap-check", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"channel_a":1,"channel_b":6}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"channel_a":1,"channel_b":6}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/misc2/wifi-channel-overlap-check", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"channel_a": 1,
"channel_b": 6
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "misc2.wifi_channel_overlap_check",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |