Does the Password Strength Checker talk to Active Directory?

No. It runs entirely inside the browser, counts Unicode code points locally, and never makes a network call. It cannot see your actual domain policy, your password history, or your fine-grained overrides; only the domain controller sees those.

Can a Strong score still fail Active Directory's complexity requirement?

Yes. A long quote, a reused secret, or a leaked passphrase can score Strong on length and pattern checks yet be guessed quickly. The label covers only documented local length and simple-pattern checks; the domain controller always has the final say on history and composition.

Does Active Directory block passwords shorter than 8 characters by default?

On Windows Server 2022 and newer, the default minimum length is 8 characters. On Windows Server 2016 and 2019, it is 7 characters. Many organizations raise the floor further, often to 12 or 14, so always read your actual policy.

Where do I check my own domain's actual password policy?

Run net accounts from a command prompt for a quick view, gpresult for the policy object source, or Get-ADDefaultDomainPasswordPolicy in PowerShell for the authoritative default-domain policy. For a single user, run Get-ADUserResultantPasswordPolicy.

Does the meter check breached passwords?

No. The tool makes no network query and cannot know whether a value appears in a current breach corpus. Use the account provider's full blocklist check, and follow any breach warning you receive, even when the local meter reports Strong.

Do I need uppercase, numbers and symbols in my Active Directory password?

When the complexity flag is on, the password must contain characters from at least three of the five groups: uppercase, lowercase, digits, non-alphanumeric symbols, and Unicode alphabetic. The local meter reports the groups present but does not enforce composition; the domain controller enforces it.

Verify a Password Meets Active Directory's Complexity Rules

Active Directory's default password complexity policy requires a minimum of 7 characters on Windows Server 2016 and 2019, or 8 characters on Windows Server 2022 and later, and demands that the password contain characters from at least three of five groups: uppercase letters, lowercase letters, digits, non-alphanumeric symbols, and any Unicode character Windows classifies as alphabetic. The five-group rule is the famous 3-of-5 composition check that fires whenever a domain controller processes a password change. If your candidate string fails any of these conditions, the controller rejects the change and you see an error that names the requirement it missed. Because that error is shown only at the moment of submission, most users want a way to evaluate a candidate in advance. Reading the domain's actual policy, then reviewing the candidate locally with a transparent meter, lets you walk into the password-change dialog already knowing whether the value will pass.

how to check password complexity requirements in active directory

Active Directory's Default Password Complexity Policy

The policy that ships with a new Active Directory domain is set by the Default Domain Policy and is enforced by every domain controller. The relevant settings live under Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Password Policy. Two of those settings drive complexity directly: Minimum password length and Password must meet complexity requirements.

The minimum length is the hard floor; anything shorter is rejected before complexity is even evaluated. The default value changed between Windows Server releases. On Windows Server 2016 and 2019 the default is 7 characters. On Windows Server 2022 and newer the default is 8 characters. Many organizations raise the floor further, often to 12 or 14, to align with current NIST SP 800-63B guidance on memorized secrets.

The complexity flag enables the 3-of-5 composition rule. When it is on, the controller classifies every character in the proposed password and counts how many of the five groups appear. The candidate must hit three distinct groups or be rejected. The five groups are:

Uppercase letters - English A-Z and any other Unicode uppercase letter that Windows recognizes.
Lowercase letters - English a-z and any other Unicode lowercase letter.
Digits - 0 through 9.
Non-alphanumeric symbols - characters such as !, @, #, $, %, punctuation marks, and mathematical operators.
Unicode characters - any character classified as alphabetic by Windows that is not in the first three groups, including accented Latin letters, Cyrillic, Greek, and others.

The 3-of-5 rule is a composition rule, and composition rules are exactly what the OWASP Authentication Cheat Sheet flags as a weakness: users respond to forced composition by making predictable substitutions, such as capitalizing the first letter and appending a digit. Length and blocklist screening protect accounts more than composition does, but composition is still the rule Active Directory enforces when the flag is on.

Reading Your Actual Domain Policy

The default values above describe a freshly built domain, not necessarily the policy you live with. Before you test a candidate, read the real policy so you know the exact floor you are aiming for. Three methods work without installing anything new.

From a member workstation, using net accounts:

Open Command Prompt.
Type net accounts and press Enter.
Read the Minimum password length, Length of password history maintained, Maximum password age (days), and Minimum password age (days) lines.

This shows the effective policy applied to the local computer. If a fine-grained password policy overrides it for a specific user, net accounts will not reflect that override; you need one of the next two methods.

Using gpresult for the policy source:

Open Command Prompt.
Type gpresult /r | findstr "Default Domain Policy" to confirm the policy object is applied.
Run gpresult /h gp.html to produce an HTML report you can open in a browser, then expand Computer Configuration > Windows Settings > Security Settings > Account Policies.

Using PowerShell, against the domain directly:

Open PowerShell with the Active Directory module loaded.
Run Get-ADDefaultDomainPasswordPolicy to read the default policy for the entire domain.
For a specific user, run Get-ADUserResultantPasswordPolicy -Identity samAccountName to see any fine-grained override.

Policy setting	Default value	What it controls
Minimum password length	7 (Server 2016/2019), 8 (Server 2022+)	Hard floor on character count
Password must meet complexity requirements	Enabled	Forces 3 of 5 character groups
Maximum password age	42 days	How long a password remains valid
Minimum password age	1 day	Minimum time before another change
Password history	24 passwords remembered	Reuse prevention count
Account lockout threshold	0 (disabled) by default	Failed attempts before lockout

Pre-Check a Candidate Against Those Rules

Once you know the floor your domain enforces, you can evaluate a candidate before opening the password-change dialog. A local review tool is the fastest way to do this without ever transmitting the candidate string. The Password Strength Checker runs entirely in the browser, counts Unicode code points rather than UTF-16 units, reports the descriptive character-group count, flags simple repeated chunks and four-character monotonic sequences, and applies published length bands that mirror current NIST guidance.

Open the Password Strength Checker and type or paste the proposed password. The input stays local and hidden unless you press Show; nothing leaves the browser.
Read the length in code points and the character-group summary. For an Active Directory candidate, confirm you have at least three groups represented - uppercase, lowercase, digit, symbol, or Unicode alphabetic - and that the length is at or above your domain's minimum.
Check the pattern flag. A simple repeated chunk or an ascending or descending four-character run will cap the score at Fair regardless of length, which is a useful signal that the candidate is too predictable even though it would pass the composition rule.
Read each recommendation. Adjust the candidate by adding length first, then uniqueness, rather than chasing the composition rule with substitutions like Password1!.
When the local meter is satisfied, submit the password through the normal Active Directory change dialog and confirm the controller accepts it. Pair it with a unique entry in a password manager so reuse does not undermine the strength.

This sequence catches the most common rejection causes - too short, only two character groups, or a visibly obvious pattern - before you waste a password-change attempt and trigger a history-counter increment.

How the Meter Counts Length

A Unicode code point is one scalar value, regardless of how many bytes or UTF-16 units it takes to store. The meter counts code points, and so does Active Directory's own classification step, which keeps the two reviews aligned.

Formula: Length in code points = number of Unicode scalar values in the string

Example string: cat-Dog-2026-🌅

Counting each scalar: c-a-t (3) + dash (4) + D-o-g (7) + dash (8) + 2-0-2-6 (12) + dash (13) + sunrise emoji (14). The result is 14 code points. The sunrise emoji contributes exactly one code point even though it occupies two UTF-16 units on the wire. The candidate therefore reports 14 characters, which clears the default 8-character floor. The character-group summary shows lowercase letters, uppercase letters, digits, a symbol, and a non-ASCII character - five of the six groups the meter reports - so the value satisfies Active Directory's 3-of-5 complexity rule on those grounds as well.

Why a Local Meter Cannot Replace Domain Enforcement

A local review gives you an early signal, but the domain controller is always the source of truth. Three checks happen only on the server side:

Password history. The controller compares your new value against the last 24 hashes (or whatever your policy says); a local meter cannot see those hashes.
Per-user fine-grained policy. Administrative accounts or privileged groups may have a higher minimum length and a stricter lockout policy that Get-ADDefaultDomainPasswordPolicy does not show; only Get-ADUserResultantPasswordPolicy does.
Azure AD override for hybrid identities. When a user is synchronized to Microsoft 365, the cloud-side default policy is 8 characters with the same complexity rule, but additional controls such as banned-password detection run on the cloud and cannot be inspected from a local browser tool.

For these reasons, the meter is best described as a pre-check, not a guarantee. Treat its Strong label as evidence that the candidate is plausibly good, then confirm acceptance on the server.

Beyond Composition: What Actually Protects an Account

Composition rules are easy to satisfy and easy to game. The protections that materially reduce account takeover are different.

Length. Per NIST SP 800-63B, passwords shorter than 15 characters are weak when they are the only authentication factor. Aim for 15 to 20 or more characters whenever the service accepts them.
Uniqueness. Reusing a password across systems turns any single breach into a multi-system compromise. Generate a fresh value for every account using a local password generator and store it in a manager.
Blocklist screening. Compare the full proposed value against the account provider's known-leaked-password list. This is what catches Password1! even though it satisfies the 3-of-5 rule.
Multi-factor authentication. A second factor, especially a phishing-resistant passkey or hardware token, neutralizes a guessed or stolen password entirely.
Reactive change. Rotate a password when it is reused, exposed, or suspected of compromise, rather than on a calendar cycle.

Combining these five controls is the real defense. The composition check that Active Directory runs is one slice of a layered approach, not the layer that keeps attackers out.