The address in the recipient's instructions and the address pasted into a wallet look almost identical. A wallet may report a checksum error, but that message does not show exactly what changed while moving the text. Investigating requires two strings: the original instruction and the actual contents of the destination field. Checking either string alone does not answer whether they are equal.
This article concerns comparing copies. KOT.CASH already has a general crypto address validator, which checks formats and checksums. The tool below compares two strings character by character, preserves their differences and additionally reports EIP-55 information for strings with the expected Ethereum format.
| Difference | What comparison reveals | What cannot be concluded automatically |
|---|---|---|
| Case only: A โ a | The text differs, but the hexadecimal values can match | That mixed-case checksum encoding remains correct |
| A value changes: 5 โ 6 | The address's value sequence changes | That recalculating capitals will restore the recipient |
| A space U+0020 is added | There is an extra character and the full text fails the expected format | That the space was the original instruction's only problem |
| An invisible U+200B is added | Comparison reports the character code even when it cannot be seen | Who added it or at which stage |
| A character is missing | A deletion and its source position are reported | Which source is trustworthy without a separate check |
Obtain two independent copies
Take the first string from the current instructions for the intended operation. Take the second from the field where the destination is being entered. Copying an already changed address twice from the same place will naturally produce an exact match, without explaining the transfer from the initial instructions. The tool does not establish source authenticity: the user must provide that condition for the comparison.
The original field accepts 0x followed by forty hexadecimal characters. The second field can contain incomplete text so that omissions remain visible. Avoid removing spaces beforehand, since that discards part of the explanation. The tool does not automatically read the clipboard; the user supplies both strings.
Separate three results
- Exact text match. The entire text is compared, including prefix, letter case and spaces. This answer concerns only the submitted strings.
- Same hexadecimal values. If both strings have the expected format, case-insensitive comparison establishes whether their address sequences match. When the format is unsuitable, this result remains undetermined.
- Checksum casing. EIP-55 is computed separately for suitable strings. Correct checksum casing does not establish equality between two different addresses.
In the default example, the original contains an uppercase A and the second copy has a lowercase a in its place. The tool reports one replacement at position 5 when counting from the beginning of the complete string, including 0x. The texts differ, their address values match, and the second copy's mixed-case checksum does not match EIP-55. These answers are consistent because they test different properties.
Why the edit list is not an incident history
The tool constructs one minimum sequence of replacements, insertions and deletions, with equal cost for each operation. Characters are counted as Unicode code points, so an inserted emoji occupies one position in this comparison. Invisible characters have codes such as U+200B reported. Positions start at one and include the prefix.
If repeated characters permit several equally short alignments, one is displayed. The algorithm cannot know whether the real actions followed that sequence. A deletion in the report does not prove a manual typo; a different complete string does not prove malware. This describes a textual discrepancy rather than investigating its cause.
What the supplementary EIP-55 check means
The checksum form uses Keccak-256 of the forty lowercase characters without the prefix. Mixed-case input is checked for agreement; uniform-case input has no mixed-case verdict. The canonical form itself can sometimes be entirely uppercase or lowercase. The chain-aware EIP-1191 variant is not applied here.
A new checksum form computed for incorrectly entered values remains the form of a different address. It does not restore the initial instructions.
Avoid resolving an unexplained discrepancy by changing capitalization alone. The general KOT.CASH validator helps inspect one string; copy comparison helps determine what changed between two submitted versions. Even successful results from both tools neither select a network nor establish ownership or deposit support.
Finish the check before a swap
If differences appear, return to the operation's current instructions and clarify anything uncertain with the recipient or support. Check the complete string, asset and network separately. This tool runs locally, makes no explorer requests and sends no transactions. It also cannot know which address will actually remain in the wallet after the final edit: inspect the final contents of the destination field.
Compare the original address and pasted copy
Positions start at 1 and include 0x. Preserve spaces and invisible characters for diagnosis. One minimum edit alignment does not prove a cause. Example is not payment instructions; network and recipient are unchecked. The calculation runs on your device; nothing you enter is sent anywhere.