You can find which version of Windows you are running by opening Settings > System > About (Windows 11) or Settings > System > About (Windows 10), or by pressing Win+R, typing winver, and pressing Enter. The winver dialog reports the edition and the OS build number, and the build number is the detail that actually identifies your release. For older systems, the System Control Panel or the command prompt command verrom (or systeminfo) returns the same information. The version name alone is not enough, because Windows 10 and Windows 11 share the same major kernel version number, 10.0. [Microsoft]
That sharing is the root of most confusion. Windows 11 does not report kernel version 11.0. It reports 10.0 with a higher build number. So the number "10.0" appears on both operating systems, and the build number is what separates them. This single fact explains why so many people who check "version" get an answer that looks wrong, and why the build number is the field you should trust.
Mechanism: How Windows Encodes Its Own Identity
Windows carries its identity in a version resource inside system files, and the winver dialog reads that resource. The version resource has four fields, and each means something different. Major and minor versions are 10 and 0 for both Windows 10 and Windows 11. The build number increments with each feature update and each cumulative update. The revision number, often called UBR (update build revision), increments with each monthly quality update.
The build number is the meaningful release identifier because Microsoft ships feature updates as new builds. Windows 10 versions were historically tied to a build range, and Windows 11 versions are tied to higher build ranges. When you see a build number, you are looking at the exact release channel and servicing level of that installation.
The winver dialog shows the edition (Home, Pro, Enterprise), the version (such as 22H2 or 23H2), and the OS build with the UBR appended. The Settings About page shows the same fields plus the system type and the installed RAM. Both read from the same underlying data, so they should agree. If they do not, one of them is stale, which usually means the Settings app has not refreshed after an update.
The command line gives you the rawest form. Running ver in cmd.exe returns the major.minor.build string. Running systeminfo returns a longer report including the OS name, version, build, and install date. The registry stores the same data under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion, where the key CurrentBuild and UBR hold the build and revision. Professionals read the registry when a script or a remote session needs the identity without a GUI.
The important distinction is between version name and build number. A version name like "22H2" describes a feature update family. The build number describes the exact binary. Two machines both on "22H2" can be on different build numbers if one has received later cumulative updates. The build number is therefore the only field that uniquely identifies what is installed.
Quantified Context: Build Ranges and What They Mean
The numbers are not arbitrary. Windows 10 builds historically occupied the 10000 to 19045 range, and Windows 11 builds start above 22000. Windows 11 21H2 shipped as build 22000. Windows 11 22H2 shipped as build 22621. Windows 11 23H2 shipped as build 22631. Windows 11 24H2 shipped as build 26100. These ranges are how support staff quickly classify a machine without reading the version label.
The UBR matters for security posture. A machine on build 22631 with a low UBR is missing monthly quality updates even though its version label looks current. Microsoft's servicing model delivers security fixes through cumulative updates that raise the UBR, so the UBR is a rough proxy for patch currency. A build number without its UBR tells you the release family but not the patch level.
The version label and the build number can disagree in ways that matter. A machine that has downloaded a feature update but not yet restarted can report the old build while Settings shows the new version as pending. The About page may show the new version name while winver still reports the old build until the restart completes. This is normal, not a fault, and it resolves after the reboot.
There is also the Windows Insider channel. Insider builds carry build numbers well above the retail ranges, sometimes in the 26000s or higher for the Dev Channel. If you see a build number far above the retail line for a given version, the machine is likely enrolled in the Insider Program. The About page shows the Insider channel in that case, which is the fastest confirmation.
Edge Cases That Break the Simple Answer
Windows Server complicates the picture. Windows Server 2022 reports kernel version 10.0 and a build in the 20348 range, which sits between Windows 10 and Windows 11 builds. A user who assumes "10.0 means Windows 10" will misclassify a server. The About page and winver both show the product name, so read the product name rather than inferring from the kernel number.
Windows 10 in S mode and Windows 11 in S mode report the same version and build as their standard editions. The S mode restriction is a separate flag, visible on the About page as "Windows 10 Home in S mode" or similar. Checking the version alone will not reveal S mode, so if that distinction matters, look for the S mode label.
Virtual machines and cloud instances can report a build number that does not match the host. A VM runs its own Windows image, so its version and build are whatever that image contains. Do not assume a VM inherits the host's update level. The same applies to Windows containers, whose base image may be an older build than the host.
Long-term servicing builds for embedded and specialty systems can lag the retail line by years. Windows 10 IoT Enterprise LTSC builds stay on a fixed build for their support lifetime, so their build number looks old even though the system is fully supported. If you are auditing an embedded device, the version label plus the LTSC designation is the correct identity, not the retail build range.
The counterintuitive detail: a machine can be fully up to date on Windows 10 and still report a build number lower than an out-of-date Windows 11 machine. Build numbers are not a universal freshness score across versions. They only order machines within the same version family. Comparing a Windows 10 build to a Windows 11 build tells you which OS family each is in, not which is better patched.
Misconceptions and Red-Flag Warnings
The most common misconception is that Windows 11 must report version 11.0. It does not. The kernel version stays 10.0 for compatibility, and the build number is the real separator. Anyone who tells you to check for "11.0" is giving you advice that will fail.
Another misconception is that the version name, such as 22H2, is enough to identify the release. It is not, because cumulative updates change the build and UBR without changing the version name. Two machines on 22H2 can be weeks apart in patch level.
Watch for these warning signs when checking a version:
A build number that does not match the version label shown on the same screen, which usually means a pending restart. A build number far above the retail range for the labeled version, suggesting Insider enrollment. A product name that says Server or IoT while the kernel version says 10.0, which means the kernel number is misleading. A UBR of zero or a very low UBR on a machine that claims to be current, suggesting update failures. Settings and winver disagreeing after a reboot, which can indicate a corrupted update or a partially applied feature update. A version label that is past its end-of-servicing date, which means the machine is unsupported regardless of build number.
The professional caveat is that version checks done through remote management tools can be stale. A management console may cache the last reported build and show it as current even after the machine updated. Always confirm on the device itself, or force a refresh in the management tool, before treating a reported build as authoritative.
Comparison of Identification Methods
| Method | What it shows | Best for | Limitation |
|---|---|---|---|
| Settings > System > About | Edition, version, build, UBR | Everyday users | Can lag after an update until refreshed |
| winver dialog | Edition, version, build, UBR | Quick confirmation | No system type or RAM |
| ver in cmd.exe | Major.minor.build | Scripts and quick checks | No edition or UBR |
| systeminfo | Full OS report, install date | Audits and support | Slow on some systems |
| Registry CurrentVersion key | Build and UBR raw values | Automation and remote checks | Requires registry access |
| Management console | Cached reported build | Fleet overview | Can be stale |
The table makes the tradeoff clear. GUI methods are readable but can lag. Command line and registry methods are exact but terse. A management console is convenient but not authoritative on its own. For a single machine, winver is the fastest reliable answer. For a fleet, pair the console with a spot check on the device.
Timeline of a Windows Release and Its Build
| Stage | What happens | What you see |
|---|---|---|
| Feature update offered | New build downloads in background | Old build still reported |
| Download complete, pending restart | Files staged | Settings may show new version, winver shows old build |
| Restart completes | New build active | Version and build both update |
| Monthly quality update | UBR increments | Build number same, UBR higher |
| Feature update superseded | Newer build offered | Older build remains until upgrade |
| End of servicing reached | No more security updates | Build frozen, version unsupported |
This timeline explains the most confusing moment in version checking: the window between download and restart. During that window, different tools can honestly report different things. The machine is in transition, and the correct answer depends on whether you are asking what is installed or what is pending. After the restart, the two converge.
The end-of-servicing stage is the one that matters for security. Once a version reaches its servicing end, the build stops receiving security updates even though it still reports a valid-looking version and build. The build number alone will not tell you this, which is why the version label plus Microsoft's servicing dates is the complete picture.
Practical Actions: Checking Your Version in Under a Minute
Use these steps in order, stopping when you have the answer you need.
Press Win+R, type winver, press Enter. Read the version and the OS build with the UBR in parentheses. This is the fastest authoritative check. Open Settings > System > About. Confirm the edition, version, and build match winver. If they differ, restart and recheck. For a script or remote check, run ver in cmd.exe for the build, or systeminfo for the full report including install date. Read the product name, not just the kernel number. If it says Server or IoT, treat the kernel 10.0 as non-diagnostic. Compare the build number against the version family ranges to confirm the release, then check the UBR against the latest monthly update for patch currency. If you manage a fleet, spot-check three to five devices with winver and compare against the console to detect stale reporting.
Set a threshold for action. If the UBR is more than one monthly cycle behind the latest quality update for that build, investigate the update pipeline. If the version label is past its servicing end, plan an upgrade rather than a patch. If Settings and winver disagree after a reboot, treat it as a failed or partial update and check the update history.
For most people, the winver dialog is enough. It answers the question directly, shows the build that actually identifies the release, and takes about five seconds. The deeper checks exist for support staff, auditors, and anyone managing more than one machine. The principle is the same at every scale: trust the build number and the product name, and treat the version label as a family name rather than an identity.
Limitations: build ranges shift with each release cycle, and Microsoft can revise servicing dates, so confirm the current ranges and support windows against Microsoft's official release health documentation before relying on them for compliance decisions. The methods above identify the installed release; they do not verify update integrity or security posture on their own.
This article is general educational information about identifying a Windows release, not a security audit, compliance certification, or professional support recommendation. For managed fleets or regulated environments, consult a qualified IT professional or your organization's support provider before making upgrade or patching decisions.