No—accents are not removed when you use the Palindrome Checker. Accented letters remain in the normalized comparison string: “Été” becomes “été” and is reported as a palindrome; it is not converted to “ete.” The checker applies Unicode NFKC normalization and fixed English-locale lowercase, but it does not perform accent stripping or language-specific transliteration.
That distinction matters because the tool compares the visible spelling, not pronunciation, translated meaning, or a looser notion of sameness. The source entry is not modified by the check; instead, the checker displays the letters-and-numbers string it actually used, together with the verdict and retained-character count.
How accents are normalized
The Palindrome Checker follows one explicit policy. It applies NFKC, lowercases with a fixed English locale, and then keeps only Unicode characters classified as letters or numbers. An accented letter remains a letter, so its diacritic is carried into the comparison. NFKC can standardize the internal representation of compatible or canonically equivalent text, but it does not turn “é” into “e.”
After filtering, the tool compares Unicode code points from the two ends toward the center and stops at the first mismatch. An accented character and its unaccented base letter therefore do not match under this policy. The comparison uses code points rather than raw UTF-16 code units, so supplementary characters are not split during the check.
For example, “Été” normalizes to “été” and returns yes. A word such as “résumé” stays accented rather than becoming “resume,” and its mirrored positions do not match. These examples show the difference between normalization and accent removal: normalization makes eligible text comparable under a stated rule; it does not erase linguistic marks or decide that two spellings are interchangeable.
| Text element | Published treatment | Effect on the palindrome test |
|---|---|---|
| Accented letters | Retained after NFKC normalization and lowercasing | The diacritic remains part of the compared character |
| Uppercase and lowercase | Lowercased with a fixed English locale | Capitalization does not affect the verdict |
| Spaces | Excluded from the comparison string | Word and phrase gaps do not count |
| Punctuation | Excluded from the comparison string | Separators do not count as matching characters |
| Symbols and emoji | Excluded from the comparison string | They are not comparison units |
| Compatibility characters | Processed through NFKC normalization | Compatible forms may compare alike, but this is not accent removal |
Because the preview and the verdict use the same retained string, you can audit the decision instead of guessing which spaces, punctuation, symbols, or emoji were excluded. For a long input, the comparison string appears in a bounded scrollable panel, while the retained-character count records the size of that normalized string.
Check accented text in three steps
- Enter the original word, phrase, sentence, or number. Include its accents rather than converting them in advance. The checker accepts up to one million Unicode code points and never truncates text to manufacture a result.
- Run the check and inspect the normalized string. Look for each accent-bearing letter in the displayed letters-and-numbers string. Spaces, punctuation, symbols, and emoji will be absent because they are outside the retained scope.
- Read the verdict and retained-character count. Confirm that the preview matches the characters you intended to test. If a contest has its own rule, compare it with the checker’s published normalization before accepting the result as contest-compliant.
This workflow answers the exact question at hand: it tests the accented spelling as entered under the published rule. It does not request an accent-stripped spelling, expand language-specific equivalences, or substitute pronunciation for the written characters.
Why keeping accents can change the verdict
Accent placement is part of each compared character. If two mirrored positions contain an accented letter on one side and its plain counterpart on the other, they are different code points and the result is no. Adding accents to only one half of an otherwise symmetrical phrase can therefore change a yes into a no.
Encoding can look different to a person even when the checker can compare the result consistently. A character such as “é” may be typed as one precomposed character or as “e” followed by a combining accent mark. NFKC can standardize those representations for comparison, so inspect the normalized preview to see the actual retained form. It still preserves the accent itself.
The published rule is suitable when the objective is to check an exact visible spelling. It is not a pronunciation test, translation check, or semantic-equivalence system. The checker does not expand every language-specific equivalence, identify word boundaries, or decide whether a sentence is meaningful. Its yes-or-no answer applies to one documented comparison string.
Match the rule to the task or contest
Palindrome challenges do not all use the same policy. Some ignore case, spaces, and punctuation; others demand character-for-character equality. Some may specify that accents should be ignored, while others treat the accented spelling as part of the puzzle. The Palindrome Checker’s result is reproducible under its published rule, but that rule is not universal.
If the instructions say to ignore accents, do not assume this checker’s result already applies that instruction. Follow the contest’s stated rule instead. If the goal is to create a separate unaccented copy, a dedicated workflow such as removing accents from text online without losing letters may be useful, but that transformed copy is not the string produced by this checker.
| Scenario | Rule to use |
|---|---|
| Check the published Palindrome Checker rule | Keep accents, inspect the normalized preview, and use the displayed verdict |
| A contest explicitly ignores accents | Apply the contest’s accent rule separately rather than inferring it from the checker |
| A strict character-for-character challenge | Use the strict rule because the published checker ignores case, spaces, and punctuation |
| Pronunciation or language equivalence is required | Use a method intended for that rule; this checker does not transliterate or compare pronunciation |
For wordplay, classroom examples, puzzle verification, identifiers, numeric sequences, or debugging a normalization rule, an explicit policy makes the answer reproducible. Keeping the normalized string and retained count alongside the verdict lets another person examine exactly which characters were tested.
Limits and errors that affect the check
The tool requires at least one retained letter or number, and several input conditions end in an explicit error rather than a partial verdict. These boundaries keep normalization, filtering, preview rendering, and comparison predictable for long passages.
| Input condition | Result |
|---|---|
| At least one retained letter or number | The checker returns the normalized string, retained count, and palindrome verdict |
| Only punctuation, whitespace, or emoji | An explicit error is returned because no comparison characters remain |
| Empty input | The check fails without a partial verdict |
| Malformed UTF-16 | The check fails without a partial verdict |
| More than one million Unicode code points | The check fails without truncating the source text |
Normalization, filtering, counting, and comparison all run locally in the browser, with no account or upload required. The retained-character count describes the normalized comparison string, not the total number of characters in the original entry. It can therefore be lower because excluded characters such as spaces, punctuation, symbols, and emoji are not retained.