# Changelog
Source: https://docs.cipherinspector.com/changelog/changelog
Changelog of all updates and changes to CipherInspector.
# June 17, 2026 update
After several months of operation, CipherInspector is moving to a client-side only model. Enigma has been discontinued alongside the account system due to low adoption.
Going forward, all accounts and their data will be deleted. The website has been updated to no longer include a login page, privacy policy, or support, and the experience has been centered around the playground and solvers tab.
Thanks for supporting CipherInspector.
# February 9, 2026 update
Welcome solvers to the party! Solvers implement client-side processing for running the optimal search pattern for solving various ciphers. The first solver is available now for solving Vigenere ciphers. More on the way soon.
Patched a bug where private dashboards were not showing in the dashbaord after creation.
![Solvers tab with Vigenere solver]()
# January 29, 2026: CipherInspector 1.0 releasing February 4th!
After several months of development, the full launch of CipherInspector is finally here. Building off the learnings of the prototype "Artemis" dashboard, CipherInspector comes with more widgets, more customization, and more robust architecture to support advanced tooling in the future.
## Widgets
CipherInspector will launch with 12 widgets, all with multiple different views (one of them comes with six different subtools!)
* Frequency Analysis
* Index of Coincidence
* Kasiski Examination
* Missing Characters
* ASCII Distribution Chart
* Bitstream Variance
* Shannon Entropy
* Expected Bin Occupancy
* Normal Order (Normor)
* Chi-Squared Test
* Kolmogorov-Smirnov Test
* Levenshtein Distance
* Title widget (formatting)
## Ciphertexts
Ciphertexts have seen a complete overhaul. They are stored as bitstreams after being decoded from their specified character encoding. This allows a far more creative interpretation for analysis techniques, going all the way down to the binary. Ciphertexts now support many more encoding options:
* ASCII
* latin1
* UTF-8
* UTF-16
* UTF-32
* Binary
* Octal
* Decimal
* Hexadecimal
* Base64
In addition to this, ciphertexts have multiple transformations you can apply before analysis:
* Ignore whitespace
* Ignore casing
* Ignore punctuation
* Genericize
You can also fully customize the color of your ciphertext now, and give it a nickname to easily pick out ciphertexts from an alias instead of the ciphertext itself.
## Meet the Playground
The CipherInspector Playground is the successor to Artemis. It is a free experience with all widgets available for use. You can add any ciphertexts and create whatever dashboard you want!
## CipherInspector: Enigma
Also coming to CipherInspector is an enhanced experience that includes some convenient features:
* Create dashboards that are saved to your account for access later
* Create **public** dashboards that you can share with anyone via the share link
* Bookmark ciphertexts so you can access them and easily add them to any of your dashboards in a couple clicks
* Copy dashboards you create in the playground into your account and save them
* Copy any public dashboard into your account so you can modify your own copy and save it
**Note:** If you create a dashboard in the playground and decide you want to save it by upgrading to Enigma, just click the upgrade button from your playground. Once you check out, the playground dashboard will automatically be imported into your account.
## Docs
CipherInspector comes with a suite of docs to explain how everything works. Check out the docs at [docs.cipherinspector.com](https://docs.cipherinspector.com). In addition to this, the formulas used to back all of the widgets will be made into an open source library for better understanding, as well as to assist in building brute force tools.
Explore the full experience February 4th!
# October 12, 2025: CipherInspector 1.0 Announced
CipherInspector is officially in the works! The full version takes feedback from early adopters of Artemis, a prototype build.
## Key features
### Account system
Cipher inspector will now be powered by an accounts system, allowing you to log in using Google (more auth options to come later). This will allow for enhanced customization and easier retention of your dashboards.
### Dashboard storage
Your account can store dashboards! As many as you want, really. If you’re big on puzzles and cryptography, this is a great bit of news. No more saving a bunch of links, just go to your account!
### Public and Private dashboards
Dashboards you create are private by default. Only you can see and access them. If you’d like to share the dashboard, you can make it public for anyone to see via URL. Don’t worry—no one can modify your dashboard even if it’s public. Only you.
### Copy from public
Public dashboards are cool. But you might want to mess with it. Copy from public will be available so you can duplicate someone else’s dashboard and mess with it on your own.
### Shortened links
Finally, the dashboard data isn’t all stored in the URL! Whew. That was a pain. Sharing links will now be manageable.
### More tools
Targeting support for the following widgets:
* Frequency Analysis
* ASCII distribution
* IOC
* Shannon entropy
* KS test
* autocorrelation
* Chi squared
* Expected Bin Occupancy
* and many more!
![CipherInspector 1.0 announcement]()
# May 27, 2025 update
This quality of life update introduces several performance improvements, UI fixes, and features that will help users learn how to use tools they’re unfamiliar with.
* Introduces info modals for all tools to explain how they work and what they are used for.
* Updated the grid system to have an ultrawide view and no longer restrict desktop to a narrow view. This allows for 16 columns on desktop, 8 on medium displays, and the typical 1 for mobile.
* Update to the colors on the site. Made the darks a little darker.
* New logo! How fun.
* Updated the “About” page with an additional FAQ and a new bio for the website.
* Improved footer :heart:
* Introduced a feature that allows you to rename your dashboard. This is saved in the URL! Max title length of 40 characters.
* Fixed a bug where tabs would not wrap on mobile.
### Stability improvements
* Dashboards with lots of graphs and tons of data started to lag significantly, and I wanted to address this.
* Input text is now debounced so that it does not trigger a chart re-render or url regeneration on each keystroke, only when you stop typing.
* Charts will now display a skeleton placeholder when resizing widgets or the overall browser window to ensure smooth transitions without lag. If you want to see what the chart looks like at certain drag points, you can stop your drag (while keeping your mouse down) to preview the chart.
![May 27, 2025 update screenshot 1]()
![May 27, 2025 update screenshot 2]()
# May 25, 2025 update
Alright another update with some QOL changes + new feature:
### New feature: n-gram frequency analysis and IC
* Frequency analysis settings have been updated to allow you to provide the n-gram size of 1-10 for evaluation.
* Also allows evaluating based on sliding window (overlapping n-grams) or block (non-overlapping).
* Added support for n-gram analysis for Index of Coincidence.
### New Widget: KS Tests
* The Kolmogorov-Smirnov test is a non-parametric test that tests the hypothesis that two samples are drawn from the same distribution.
* In this widget, you can test the hypothesis that the distribution of the input text is the same as the distribution of the English language (Theoretical distribution).
* Your input text is compared to a reference English text, which is 500 words long and encoded in the same encoding as your input text.
### Quality of life changes
* Added the ability to "hide" and "unhide" texts from the dashboard results without deleting them. This helps when you are evaluating large data sets and need to interact with the chart for them.
* Updated the UI for changing the settings on any widget with settings. There is now a settings modal which will pop up. This gives a uniform design language across widgets.
* Fixed a bug that caused user interactions with settings buttons within widgets to trigger the drag/drop functionality, hindering the ability to click buttons in widgets.
* Ok I know I said in the last one I won't break links anymore but for realsies this time, all the widgets have been updated to follow the same abstraction as the input text, where their inputs are now encoded as an object which is compressed into the link. This means that both components of our application are now fully extensible without ruining backward compatibility (i.e., I can add more settings and metadata to existing tools without fucking with the links in a breaking way). So there, now the links should be working round the clock.
The existing link I provided in the last update actually [still works!](https://tinyurl.com/artemission2) with a caveat that some of the settings for widgets are probably reverted to default. But hey, it's progress! The abstractions are really starting to come together. It's paying dividends for new widgets and extending existing ones.
![May 25, 2025 update screenshot 1]()
![May 25, 2025 update screenshot 2]()
![May 25, 2025 update screenshot 3]()
![May 25, 2025 update screenshot 4]()
# May 24, 2025 update
More Artemis updates today! Since this thing is still sorta getting established, these changes will break any saved links, but it's to enable a ton of possibilities when making new widgets for multi-input support.
* Updates the multi-input UI to be significantly LESS ugly. Before it was this horrible pill design I rushed together to get the thing working. Now, it's an intuitive tab design that looks and feels a lot better.
* Support for different encodings and ignore options *per input* instead of being a global setting. This was a big feat, and required refactoring every single widget to ensure it would read in inputs. But this sets up a lot of awesome stuff.
* Shannon Entropy now shows an English baseline entropy and a Random text baseline entropy in each table row. These values are derived based on the encoding set on the text of that row. So if the text is base64, the english baseline is of a base64-encoded string, etc. This is also implemented in the Index of Coincidence widget.
* ASCII distribution will decode each input text based on its encoding before charting the data, ensuring we are charting the raw bytes of each input.
* Links now store compressed input *objects* rather than just compressing the input. This means we can now add more metadata to each input while remaining backwards compatible and not break links in the future.
* Gridlock: new feature that allows you to lock the dashboard so that it doesn't drag around or resize. This actually fixes some annoying stuff that was buggy about the site. Drop downs would bug out on mobile and sometimes desktop, but more importantly it allows you to click on ciphertext in the chart legend to show/hide it from the chart, which was not working before because the drag/drop stuff was interfering with taps on the widgets. Note: This also locks adding and removing widgets. However, it does not lock editing, adding, or removing text.
* Fixed some light mode display bugs, so now it is actually visually consistent.
Check out [This example dashboard](https://tinyurl.com/artemission2) with TheGiant and a few rev ciphers.
![May 24, 2025 update — light mode]()
![May 24, 2025 update — dark mode]()
# May 18, 2025 update
* Updated frequency analysis to display the percentage of overall characters instead of the count
* ASCII distribution to have three settings: input range only, ASCII, and Extended ASCII, to make it esaier to visualize and/or contextualize data.
* Updated the layout so that it can be up to 4 columns wide for desktop views
* Added checkboxes to exclude punctuation, whitespace, and casing respectively.
* Updated widgets to be drag/drop so they can be repositioned. They are also resizable. Positioning and sizing are preserved in the link, so you can share dashboards how you see them.
* Artemis now allows providing multiple texts for cross-analysis. The max is 5 distinct texts.
* Some widgets have been slightly modified to support the multi-text functionality. Frequency Standard Distribution, Shannon Entropy Summary, and IOC summary are now displayed as tabular data instead of either a graph or just a large text value.
[here is an example dashboard](https://tinyurl.com/artemission). Unfortunately with comparing very long texts, the data encoded in the url parameters even when compressed results in an extremely long URL (longer than discord's message length limit btw) so I did have to use [https://tinyurl.com/](https://tinyurl.com/) to minify the link before I could share it. YMMV.
Will add more widgets another day
![May 18, 2025 update]()
# Ciphertext Settings
Source: https://docs.cipherinspector.com/ciphertext/ciphertext-settings
Ciphertexts can be configured with various functional and non-functional settings to customize the experience.
## Functional settings
Within each cipher are settings which change how CipherInspector interprets and processes
the ciphertext during analysis. Learn more by clicking on each option:
* [Encoding](/ciphertext/encoding)
* [Ignore whitespace](/ciphertext/ignore-whitespace)
* [Ignore casing](/ciphertext/ignore-casing)
* [Ignore punctuation](/ciphertext/ignore-punctuation)
* [Genericized text](/ciphertext/genericized)
## Non-functional settings
Non-functional settings are settings that do not change how CipherInspector interprets and processes
the ciphertext during analysis. Learn more by clicking on each option:
* [Color](/ciphertext/color)
* [Nickname](/ciphertext/nickname)
# Color
Source: https://docs.cipherinspector.com/ciphertext/color
The color setting for ciphertexts.
## How it works
When creating or editing a ciphertext, you can set the display color for the ciphertext. This display color will
be reflected across all widgets. Colors are defined using [color hex codes](https://www.color-hex.com/).
# Encodings
Source: https://docs.cipherinspector.com/ciphertext/encoding
Character encoding options for ciphertexts
Character encodings on CipherInspector fall into two categories: data and display.
## Data encodings
Data encodings are character encodings that are typically used to store byte streams.
For all data encodings, the data is first decoded to a `Uint8Array` and then converted to
a string based on its encoding type (ASCII, Latin1, UTF-8, UTF-16, UTF-32). This step takes precedence over any other ciphertext settings,
unless the widget evaluates the ciphertext bytes rather than the encoded text data.
Supported data encoding types:
* [Base 64](https://en.wikipedia.org/wiki/Base64)
* [Hexadecimal](https://en.wikipedia.org/wiki/Hexadecimal)
* [Decimal](https://en.wikipedia.org/wiki/Decimal)
* [Octal](https://en.wikipedia.org/wiki/Octal)
* [Binary](https://en.wikipedia.org/wiki/Binary)
## Display encodings
Display encodings are character encodings that are already in display text format.
Display encodings are
not decoded before analysis and are analyzed as-is, unless the widget is designed
to evaluate the ciphertext bytes.
Supported display encoding types:
* [ASCII](https://en.wikipedia.org/wiki/ASCII)
* [Latin1](https://en.wikipedia.org/wiki/ISO/IEC_8859-1)
* [UTF-8](https://en.wikipedia.org/wiki/UTF-8)
* [UTF-16](https://en.wikipedia.org/wiki/UTF-16)
* [UTF-32](https://en.wikipedia.org/wiki/UTF-32)
# Genericized Text
Source: https://docs.cipherinspector.com/ciphertext/genericized
Genericized text is used to compare multiple ciphertexts in terms of their character frequencies rather than their unique characters.
## How it works
Genericized text will first collect character frequencies of your text.
```
FFFFFRRRROOOMMS
F = 5
R = 4
O = 3
M = 2
S = 1
```
It will then associate the most frequent character with the letter A, the next most frequent character with the letter B, so on and so forth.
```
F = A
R = B
O = C
M = D
S = E
```
Finally, it will replace the characters accordingly in your ciphertext to now be the genericized text.
```
FFFFFRRRROOOMMS
AAAAABBBBCCCDDE
```
### Display vs. non-display formats
CipherInspector supports many character encodings. Some are considered "display" formats,
such as UTF-8, ASCII, UTF-16, and UTF-32. Others are used to store bytes of data, such as
hexadecimal, binary, octal, decimal, and base64.
For display formats, the genericized text is calculated by counting each *character*. For
non-display formats, the genericized text is calculated by counting each *byte*.
## Interactions
The genericized text will only be computed after any ciphertext updates are saved.
The genericized text will dynamically change based on the other options set on the ciphertext:
* Ignore whitespace
* Ignore casing
* Ignore punctuation
* Reverse text
## Practical Application
This can be useful when evaluating if two pieces of text with different characters share the same unique character distribution.
## Caveats
One major caveat is that this is only practical with an alphabet size of roughly 62, but ideally no more than 26.
The reason is because we quickly run out of intuitive symbols to use. It is recommended to limit usage of genericized text to:
* Hexadecimal
* Decimal
* Octal
* Base64
* UTF-8, ASCII, UTF-16, and UTF-32 strings which are limited to a unique character set between 1 and 62.
# Ignore Casing
Source: https://docs.cipherinspector.com/ciphertext/ignore-casing
The "Ignore Casing" setting for ciphertexts.
## Functional impact
When toggling on the "ignore casing" setting for the ciphertext, characters are normalized to lowercase before analysis.
# Ignore Punctuation
Source: https://docs.cipherinspector.com/ciphertext/ignore-punctuation
The "Ignore Punctuation" setting for ciphertexts.
## Functional impact
When toggling on the "ignore punctuation" setting for the ciphertext, punctuation characters are removed before analysis.
Punctuation characters that are removed: `.,!?;:'"()\[\]{}""''…`
# Ignore Whitespace
Source: https://docs.cipherinspector.com/ciphertext/ignore-whitespace
The "Ignore Whitespace" setting for ciphertexts.
## Functional impact
When toggling on the "ignore whitespace" setting for the ciphertext, whitespace characters are removed before analysis.
# Ciphertext Nickname
Source: https://docs.cipherinspector.com/ciphertext/nickname
The nickname is a way to give an easy to read identifier to your ciphertext.
### Nicknames for readability
If you want a way to distinguish your ciphertexts easier than memorizing their first
few characters, you can use a nickname! This will display on the sidebar and inside of
widgets instead of the first few characters of the ciphertext, making it easier to identify
which cipher you are looking at.
# Introduction
Source: https://docs.cipherinspector.com/index
Welcome to CipherInspector!
## Welcome to CipherInspector Docs!
CipherInspector is a cryptanalysis dashboarding tool that enables you to create a
single view for all your analysis. There are many tools offered, all of which are
documented here to help you understand how they work. There is currently a plan to
also open source all of the formulas to get rid of any guess work.
CipherInspector offers a local playground dashboard experience, where you can create
cryptanalysis dashboards and share them via screenshots.
As of June 2026, CipherInspector Enigma has been discontinued and all account offerings
have been sunset. Dashboard links will no longer work and accounts have been shut down
with all data being deleted. The CipherInspector project will continue on as a client-side
application.
Read the docs for all available widgets on CipherInspector.
Read the docs on all available settings for ciphertexts.
# ASCII Distribution Chart
Source: https://docs.cipherinspector.com/widgets/ascii-distribution-chart
ASCII distribution shows how distributed the bytes are in terms of their 0-255 range.
## How it works
The ASCII distribution chart will use decoded ciphertext content for charting the underlying bytes of data.
UTF-8, UTF-16, and UTF-32 will be converted to a byte array, and the bytes will be evaluated.
ASCII distribution takes into consideration the settings for each ciphertext. These settings currently include:
* Ignore whitespace
* Ignore punctuation
* Ignore casing
* Genericize text
This works by decoding the ciphertext and using the number that the byte represents for each byte in the sequence.
After all of the above steps are performed, the frequency calculations are executed and mapped to the distribution chart.
## ASCII Distribution Settings
### Display range
The following options are given to adjust the display range of the chart. This can help focus on the relevant parts of the chart:
* ASCII: range of 0-127. This is the standard ASCII table.
* Extended (Default): 0-255. This is the "extended" ASCII table (latin1).
* Input range: only displays data starting from the lowest charted byte and ending at the highest charted byte.
### Count vs. Percentage
The y-axis can be toggled to use either a count or a percentage measurement.
#### Count
The count option will chart the byte frequencies in terms of raw count, and how many times they appear in the ciphertext.
#### Percentage
The percentage option will chart the byte frequencies in terms of raw count divided by total byte count.
## Practical Application
ASCII distribution analysis can be leveraged to:
* Discover if a given stream of bytes has been shifted up or down along the ASCII table.
* Determine if two or more ciphertexts follow similar character distribution.
## Caveats
* Use of this tool with UTF-8, UTF-16, and UTF-32 will produce mixed results, as these
encodings do not use single bytes to represent characters.
# Bitstream Variance
Source: https://docs.cipherinspector.com/widgets/bitstream-variance
Bitstream Variance plots the numeric value of n-bit sequences from the ciphertext as a line graph, helping you spot patterns in how the data alternates (e.g. sine-like or repeating structure).
## How it works
The widget uses the ciphertext’s decoded binary data to calculate bitstream variance. The decoded binary data
is calculated based on the encoding of the ciphertext.
Bitstream Variance takes into consideration the settings for each ciphertext. These settings currently include:
* Ignore whitespace
* Ignore punctuation
* Ignore casing
* Genericize text
For data encodings (base64, hex, octal, decimal, etc.) the ciphertext is first decoded to Latin-1 before
the toggles are applied.
The decoded byte array is converted to a single stream of bits, **MSB first** within each byte.
Example: the byte `0xA5` (165) becomes the bit sequence `1,0,1,0,0,1,0,1`.
You choose **n** from 1 to 16. Each group of n bits is turned into one plotted value:
* **n = 1**: each bit is one value (0 or 1).
* **n = 8**: each byte is one value (0–255).
* **n = 16**: each pair of bytes is one value (0–65,535).
The y-axis maximum is **2^n − 1** (e.g. 255 for n=8, 65,535 for n=16).
**Sliding (overlapping):** A window of n bits moves one bit at a time. Consecutive values overlap by n−1 bits. Only full n-bit windows produce a point; the last incomplete window is skipped.
**Block (non-overlapping):** The bitstream is split into consecutive chunks of n bits. If the last chunk has fewer than n bits, it is **padded** using the remainder setting before being converted to one value.
When the total number of bits is not divisible by n, the last block is shorter than n. You choose how to extend it to n bits before converting to decimal:
| Setting | Meaning | Example (n=4, last bits `10`) |
| ---------------- | ------------------ | ----------------------------- |
| Left pad with 0 | Zeros on the left | `0010` → 2 |
| Right pad with 0 | Zeros on the right | `1000` → 8 |
| Left pad with 1 | Ones on the left | `1110` → 14 |
| Right pad with 1 | Ones on the right | `1011` → 11 |
In sliding mode there is no remainder value; only full windows are plotted.
Each n-bit chunk is interpreted as an **unsigned integer** in big-endian order (first bit is the most significant).
Examples (n=4):
* `0010` → 2
* `1111` → 15
* `1010` → 10
For n=16, `0000000100000001` → 257.
The sequence of decimal values is plotted as a **line chart**:
* **X-axis:** Index of the value (0, 1, 2, …).
* **Y-axis:** Decimal value (0 up to 2^n − 1).
Each selected ciphertext is one line, colored by its ciphertext color. Multiple ciphertexts are overlaid with a legend.
## Bitstream Variance settings
### Bit chunk size (n)
Number of bits per value, from **1 to 16**. Larger n gives fewer points and a larger possible range (up to 65,535 for n=16).
### N-gram mode
* **Sliding:** Overlapping n-bit windows; no remainder.
* **Block:** Non-overlapping n-bit chunks; remainder is padded using the option below.
### Remainder padding
Used only in **block** mode when the bitstream length is not a multiple of n. Choose how to pad the last, shorter chunk:
* **Left pad with 0** / **Right pad with 0** — pad with zeros.
* **Left pad with 1** / **Right pad with 1** — pad with ones.
Sliding mode ignores this setting.
## Practical application
Bitstream Variance helps you:
* **See alternating patterns.** Regular up–down movement can suggest periodic structure (e.g. LFSR, repeated key, or sine-like modulation).
* **Compare ciphertexts.** Overlaying lines for several inputs can show shared or different bit-level structure.
* **Inspect raw data.** For hex/base64-decoded material, the plot reflects how byte (or multi-byte) values change along the stream, using the ciphertext’s decoded binary data.
## Caveats
* **Sliding vs block change the plot.** Sliding gives more points and overlapping structure; block gives one value per n bits. Use the mode that matches the structure you care about.
* **Remainder affects only the last value.** In block mode, the padding choice changes only the final point. For long streams the effect is small; for very short ones it can be noticeable.
* **Large n on short text.** With n=16 and very few bytes, you get only a handful of points, so the line may look flat or sparse.
# Chi-squared Test
Source: https://docs.cipherinspector.com/widgets/chi-squared-test
The Chi-squared test measures how closely the character or n-gram frequency distribution of a ciphertext matches an expected distribution.
## How it works
The Chi-squared test uses decoded ciphertext content. For data encodings (Base64, Hexadecimal, Decimal, etc.), the raw data is first decoded to bytes and then converted to characters.
Chi-squared takes into consideration the settings for each ciphertext, including:
* Ignore whitespace
* Ignore punctuation
* Ignore casing
* Genericize text
These settings are applied before frequency analysis.
The text is divided into n-grams (character groupings) based on the configured n-gram size:
* **Size 1**: Single characters (default)
* **Size 2**: Bigrams (pairs of characters)
* **Size 3**: Trigrams (triplets of characters)
* And so on...
N-grams can be generated using either:
* **Sliding window**: Overlapping n-grams (ABCD → AB, BC, CD)
* **Block mode**: Non-overlapping n-grams (ABCD → AB, CD)
The frequency of each n-gram is counted. The n-grams analyzed depend on the comparison mode:
* **English mode** (n-gram size 1 only): Only alphabetic characters (A-Z) are counted; all other characters are filtered out.
* **Ciphertext mode**: All n-grams are counted, including those with letters, numbers, symbols, and whitespace.
The Chi-squared statistic is calculated using the formula:
**X² = Σ(Oᵢ - Eᵢ)² / Eᵢ**
Where:
* Oᵢ = Observed count of n-gram i
* Eᵢ = Expected count of n-gram i
The expected count for each n-gram is calculated as: (expected percentage / 100) × total n-gram count
## Chi-squared Settings
### Comparison Mode
#### English Frequencies (Default)
Compares the ciphertext against standard English letter frequencies. **Only available for n-gram size 1** (single characters), since we only have reference frequencies for individual letters.
Only alphabetic characters (A-Z) are analyzed; all other characters are filtered out before comparison.
#### Another Ciphertext
Compares the ciphertext against the n-gram frequency distribution of a selected "base" ciphertext. Works with any n-gram size.
After applying the ciphertext settings (ignore whitespace, ignore punctuation, etc.), all remaining n-grams are analyzed.
When this mode is selected, you choose which ciphertext serves as the baseline for comparison.
### N-gram Settings
#### N-gram Size
Controls how many characters are grouped together for frequency analysis:
* **1** (default): Analyze single character frequencies
* **2**: Analyze bigram (two-character) frequencies
* **3**: Analyze trigram (three-character) frequencies
* **4+**: Analyze larger n-gram frequencies
Larger n-gram sizes can reveal patterns in polyalphabetic ciphers or detect repeated sequences.
**Note**: English frequency comparison is only available for n-gram size 1.
#### N-gram Mode
* **Sliding Window**: Creates overlapping n-grams. For "ABCD" with size 2: AB, BC, CD
* **Block**: Creates non-overlapping n-grams. For "ABCD" with size 2: AB, CD
Sliding window produces more n-grams and may reveal more patterns, while block mode treats the text as discrete chunks.
### Display Type
#### Table
Shows a summary for each ciphertext including:
* Chi-squared score
* Score interpretation
* Number of n-grams analyzed
#### Graph
Displays a bar chart showing each n-gram's contribution to the overall Chi-squared score:
* **English mode**: Letters arranged by English frequency (most common to least common)
* **Ciphertext mode / N-gram mode**: N-grams arranged by observed frequency
## Score Interpretation
| Score Range | Interpretation |
| ----------- | --------------------- |
| 0 - 30 | Excellent match |
| 30 - 50 | Very good match |
| 50 - 100 | Good match |
| 100 - 150 | Moderate deviation |
| 150 - 300 | Significant deviation |
| 300+ | Very different |
Lower scores indicate that the n-gram frequency distribution more closely matches the expected distribution.
## Practical Application
Chi-squared analysis can be leveraged to:
* **Identify plaintext**: A Chi-squared score near 0-50 against English frequencies suggests the text may be plaintext or a simple transposition cipher.
* **Detect substitution ciphers**: Higher scores (100-300) often indicate substitution ciphers.
* **Analyze polyalphabetic ciphers**: Using bigram or trigram analysis can reveal patterns not visible in single-letter analysis.
* **Compare ciphertexts**: Use ciphertext comparison mode to determine if two encrypted messages share similar n-gram distributions.
* **Detect repeated patterns**: Larger n-gram sizes can identify repeated sequences in ciphertexts.
## Caveats
* **English mode** only supports n-gram size 1 (single letters) because we don't have reference frequencies for English bigrams, trigrams, etc.
* Short ciphertexts may produce unreliable results, especially with larger n-gram sizes.
* Larger n-gram sizes produce fewer total n-grams, which may reduce statistical significance.
* When comparing against another ciphertext, ensure the base ciphertext is long enough to provide representative n-gram frequencies.
# Expected Bin Occupancy
Source: https://docs.cipherinspector.com/widgets/expected-bin-occupancy
Compare observed character frequency distribution against the expected random distribution with statistical confidence bands.
## How it works
Expected Bin Occupancy is a statistical analysis tool that compares how characters are distributed in your ciphertext against what would be expected from a purely random distribution. This
helps identify whether a text exhibits patterns that deviate from randomness.
The widget first decodes the ciphertext content based on its encoding type. Data encodings (Base64, Hex, etc.) are converted to their underlying byte representation, while display
encodings (UTF-8, ASCII) are processed directly as text.
Before analysis, any ciphertext preprocessing options are applied:
* Ignore whitespace
* Ignore punctuation
* Ignore casing
* Genericize text
These settings affect which characters are included in the frequency count.
The widget counts how many times each unique character appears in the processed text. These frequencies are then sorted from highest to lowest, creating a ranked distribution where "Bin
1" contains the most frequent character, "Bin 2" the second most frequent, and so on.
Using order statistics, the widget calculates what the expected frequency distribution would be if characters were distributed randomly (like balls thrown randomly into bins). This
creates the theoretical "expected curve" for comparison.
Statistical confidence bands are calculated around the expected curve. These bands show the range within which the observed distribution would likely fall if the text were truly random,
given the selected confidence level.
## Understanding the Chart
The chart displays three key elements:
### Observed Distribution (Solid Line)
This line shows your actual ciphertext's character distribution. Each point represents a "bin" (unique character) ranked by frequency, with the most common character on the left.
### Expected Curve (Dashed Line)
This dashed line shows what the distribution would theoretically look like for random text of the same length with the same number of unique characters. It serves as a baseline for comparison.
### Confidence Bands (Shaded Area)
The shaded region around the expected curve represents the statistical confidence interval. If your observed distribution falls within this band, it is statistically consistent with random
distribution at the selected confidence level.
## Settings
### Ciphertext Selection
Unlike other widgets that can display multiple ciphertexts simultaneously, Expected Bin Occupancy analyzes one ciphertext at a time. This is because overlaying multiple distributions would make
the comparison against the expected curve difficult to interpret.
### Show Expected Curve
Toggle the display of the theoretical expected distribution curve. When enabled, a dashed blue line shows what random distribution would look like.
### Show Confidence Bands
Toggle the display of the confidence interval bands around the expected curve. When enabled, a shaded area indicates the statistical bounds.
### Confidence Level
Select the width of the confidence bands:
* **68% (1σ)**: Narrowest band. Approximately 68% of random samples would fall within this range.
* **95% (2σ)**: Medium band (default). Approximately 95% of random samples would fall within this range.
* **99.7% (3σ)**: Widest band. Approximately 99.7% of random samples would fall within this range.
Higher confidence levels produce wider bands and are more forgiving of deviation from the expected curve.
## Practical Applications
Expected Bin Occupancy analysis can help you:
* **Detect non-random patterns**: If your observed distribution consistently falls outside the confidence bands, the text likely contains structure or patterns inconsistent with random data.
* **Compare encryption quality**: Well-encrypted data should produce a distribution that closely follows the expected random curve.
* **Identify substitution ciphers**: Simple substitution ciphers often preserve the frequency distribution of the original language, causing significant deviation from the expected random
distribution.
* **Validate randomness**: Test whether data that should be random (keys, nonces, etc.) actually exhibits random-like character distribution.
## Interpreting Results
### Distribution Within Confidence Bands
If your observed line stays mostly within the shaded confidence region, the character distribution is statistically consistent with randomness. This doesn't prove the text is random, but it
doesn't show obvious patterns.
### Distribution Outside Confidence Bands
If the observed line significantly deviates from the confidence bands—especially if it shows a steeper curve (some characters appear much more frequently than others)—the text likely contains
non-random structure. This is typical of:
* Natural language text
* Simple substitution ciphers
* Encoded but not encrypted data
### Flat vs. Steep Curves
* **Steeper observed curve**: Some characters dominate while others are rare (typical of natural language)
* **Flatter observed curve**: Characters are more evenly distributed (closer to random)
## Caveats
* **Single ciphertext only**: This widget analyzes one ciphertext at a time for clarity of comparison.
* **Sample size matters**: Very short texts may show high variance even if they come from a random source. Longer texts provide more reliable comparisons.
* **Character set assumptions**: The analysis assumes each unique character represents a distinct "bin." For multi-byte encodings, this may not reflect the underlying data structure accurately.
* **Statistical interpretation**: Falling within confidence bands suggests consistency with randomness but does not prove randomness. Conversely, falling outside may indicate patterns but could
also occur by chance with the stated probability.
# Frequency Analysis
Source: https://docs.cipherinspector.com/widgets/frequency-analysis
Frequency Analysis is the practice of evaluating n-gram frequencies across a text.
## How it works
Frequency analysis will be different based on the character encoding of your input.
For all data encodings, the data is first decoded to a `Uint8Array` and then converted to
a string based on its encoding type (ASCII, Latin1, UTF-8, UTF-16, UTF-32). This step takes precedence over any other ciphertext settings,
unless the widget evaluates the ciphertext bytes rather than the encoded text data.
Display encodings are
not decoded before analysis and are analyzed as-is, unless the widget is designed
to evaluate the ciphertext bytes.
Frequency analysis takes into consideration the settings for each ciphertext. These settings currently include:
* Ignore whitespace
* Ignore punctuation
* Ignore casing
* Genericize text
For data encodings (base64, hex, octal, decimal, etc.) the ciphertext is first decoded to Latin-1 before
the toggles are applied.
After all of the above steps are performed, the frequency calculations are executed and displayed.
## Frequency Analysis Settings
### N-grams and sliding window vs. block analysis
Frequency analysis can be performed on n-grams where `n >= 1`. For n-grams > 1, it is important
to understand the difference between sliding window and block analysis.
#### Sliding window
Sliding window analysis "slides" across the ciphertext to create n-grams. For the text `Hello`:
```
He: 1
el: 1
ll: 1
lo: 1
```
Notice that characters at a given index will appear at least twice for n > 1.
#### Block analysis
Block analysis evaluates your n-grams as non-overlapping chunks. For `Hello`:
```
He: 1
ll: 1
```
Notice that the final character, `o`, is not present. When using block analysis,
beware of missing data. The ciphertext length (*after all toggles are applied*)
must be divisible by your n-gram size for all characters to be represented in the
frequency analysis!
### Graph vs. Table
There are two display options for Frequency Analysis.
#### Graph
Shows a bar chart, where each bar is an n-gram that exists in the ciphertext(s). The height
represents the number of occurrences of the n-gram.
Graphs also have two orientations: `vertical` or `horizontal`. The orientation dictates how
the bar chart is rendered. Either the bars are vertical or horizontal.
#### Table
Shows a table of values. For ciphertexts with many unique characters, or comparing many ciphertexts,
this may be a better option.
### Count vs. Percentage
The frequency analysis y-axis can be toggled to use either a count or a percentage measurement. Note: table view
displays both count and percentage.
#### Count
The count option will chart the n-gram frequencies in terms of raw count, and how many times they appear in the ciphertext.
#### Percentage
The percentage option will chart the n-gram frequencies in terms of raw count divided by total n-gram count.
### Sort
Sorting works by picking a ciphertext to sort by. You can pick an ascending or descending sort order
for the selected ciphertext. All other ciphertexts being presented will be graphed wherever they end up
along the dictated sort order.
## Practical Application
Frequency analysis can be leveraged to:
* Exploit monoalphabetic substitution, or simple transposition.
* Determine if two or more ciphertexts follow similar character distribution.
* Compare n-gram frequencies to the expected frequency distribution of a given language
## Caveats
* Frequency analysis typically requires a sufficiently long ciphertext to be effective.
* Polyalphabetic ciphers are typically sufficient at avoiding detection via frequency analysis.
* Plaintexts designed to skew the frequency results, such as lipograms, can mislead analysis.
* Non-standard alphabets and compressed data may result in less effective analysis.
# Index of Coincidence
Source: https://docs.cipherinspector.com/widgets/index-of-coincidence
Index of coincidence calculates the probability of two randomly chosen letters from a text being the same.
## How it works
Index of coincidence (abbreviated as "IC") will be different based on the character encoding of your input.
For all data encodings, the data is first decoded to a `Uint8Array` and then converted to
a string based on its encoding type (ASCII, Latin1, UTF-8, UTF-16, UTF-32). This step takes precedence over any other ciphertext settings,
unless the widget evaluates the ciphertext bytes rather than the encoded text data.
Display encodings are
not decoded before analysis and are analyzed as-is, unless the widget is designed
to evaluate the ciphertext bytes.
IC takes into consideration the settings for each ciphertext. These settings currently include:
* Ignore whitespace
* Ignore punctuation
* Ignore casing
* Genericize text
For data encodings (base64, hex, octal, decimal, etc.) the ciphertext is first decoded to Latin-1 before
the toggles are applied.
After all of the above steps are performed, the IC calculations are executed and displayed.
## IC formula
This widget uses the following formula for calculating index of coincidence:
```
IC = (Σ(n_i × (n_i - 1))) / (N × (N - 1))
```
Where:
* `n_i` = frequency of n-gram i (or character i when n-gram size = 1)
* `N` = total number of n-grams (or characters)
* `Σ` = sum over all unique n-grams/characters
### Periodic IC formula
Periodic IC is different based on the mode.
#### N-gram mode: Block
For this mode, the process is:
1. Generate n-grams from the entire text
2. Group n-grams by their index modulo the period:
```
Group_k = {ngram_i where i % p = k} for k = 0, 1, ..., p-1
```
3. Calculate IC for each group using the basic IC formula
4. Average the IC values across all groups:
```
IC(p) = (1/p) × Σ(IC(Group_k)) for k = 0 to p-1
```
#### N-gram mode: Sliding window
For this mode, the process is:
1. Slide a window of size ngramSize across the text
2. For each window:
* Generate n-grams within the window
* Group by index modulo period (same as block mode)
* Calculate and average group ICs
3. Average the window ICs:
```
IC(p) = (1/num_windows) × Σ(IC_window) for all windows
```
## Index of Coincidence Settings
### N-grams and sliding window vs. block analysis
IC can be performed on n-grams where `n >= 1`. For n-grams > 1, it is important
to understand the difference between sliding window and block analysis.
#### N-gram mode: Sliding window
Sliding window analysis "slides" across the ciphertext to create n-grams. For the text `Hello`:
```
He: 1
el: 1
ll: 1
lo: 1
```
Notice that characters at a given index will appear at least twice for n > 1.
#### N-gram mode: Block analysis
Block analysis evaluates your n-grams as non-overlapping chunks. For `Hello`:
```
He: 1
ll: 1
```
Notice that the final character, `o`, is not present. When using block analysis,
beware of missing data. The ciphertext length (*after all toggles are applied*)
must be divisible by your n-gram size for all characters to be represented in the
IC!
### Graph vs. Table
There are two display options for IC.
#### Graph (Periodic analysis)
Shows a line chart, where each line is the periodic IC of a ciphertext. The height
represents the IC, and the horizontal axis represents how far into the ciphertext the
measurement is.
#### Table
Shows a table of values, with a single IC value for each ciphertext. This is the IC for the
entire ciphertext.
### Max Period
The max period is used in the graph to determine how far the x-axis will go. This helps with
scaling the data in case characters are of varying lengths.
#### Show Average Lines
In the periodic analysis graph, shows a dotted line for each ciphertext indicating the average line.
## Practical Application
IC can be leveraged to:
* Determine if a cipher is periodic or aperiodic.
* Discover key lengths of periodic ciphers, such as Vigenere with a repeat key.
* Compare the periods of two or more ciphers.
## Caveats
* Noisy results may mislead you.
* Autokey is a sufficient way to get rid of periodic spikes in IC.
* Coincidences in sufficiently short text may also mislead you.
* Some languages have similar IC patterns. If you don't know the language of the plaintext, you may be misled.
# Kasiski Examination
Source: https://docs.cipherinspector.com/widgets/kasiski-test
Find repeated sequences in ciphertext to determine the likely key length of polyalphabetic ciphers.
## How it works
The Kasiski examination is a cryptanalysis technique used to attack polyalphabetic substitution ciphers (like the Vigenère cipher) by
finding repeated sequences and analyzing the distances between them.
The tool scans the ciphertext for repeated character sequences (n-grams) within a configurable length range. Only sequences
appearing two or more times are considered.
For each repeated sequence, the distances between consecutive occurrences are calculated. These distances are measured in
character positions.
The key insight: if a sequence repeats, the distance between occurrences is likely a multiple of the key length. The tool
calculates all factors of each distance and counts their frequencies across all repeated sequences.
Factors that appear most frequently across all distances are the most likely key lengths. The tool ranks potential key lengths by
their frequency of occurrence.
## Display Modes
### Factor Frequency
A bar chart showing potential key lengths ranked by how often they appear as factors of the distances between repeated sequences.
**How to interpret:**
* The x-axis shows potential key lengths (factors)
* The y-axis shows how many times each factor appeared across all distance calculations
* **Tallest bars = most likely key lengths**
* Look for a clear winner or a small group of related values (e.g., 5, 10, 15 all being multiples of 5)
* If multiple bars are similar in height, the key length may be their greatest common divisor
* The chips at the top highlight the top 3 most likely candidates
### Sequence Table
A detailed table listing each repeated sequence found in the ciphertext.
**How to interpret:**
* **Sequence**: The exact characters that repeat. Longer sequences are more reliable indicators
* **Count**: Number of times this sequence appears. Higher counts provide stronger evidence
* **Positions**: Where in the ciphertext (0-indexed) each occurrence starts
* **Distances**: The gaps between consecutive occurrences. These are the key values for analysis
* **Factors**: Common divisors of the distances. Factors appearing across multiple sequences are strong key length candidates
* Look for sequences where all distances share a common factor—this strongly suggests that factor is the key length
### Text Highlighting
The original ciphertext with repeated sequences color-coded for visual pattern recognition.
**How to interpret:**
* Each color represents a different repeated sequence
* The legend shows which sequence each color represents and its occurrence count
* Hover over highlighted sections to see position details
* **Evenly spaced highlights** of the same color suggest a consistent key length
* Clusters of different colors in the same region may indicate a portion of the key that produces common letter combinations
* Sequences that appear at regular intervals (e.g., every 5th position) strongly indicate that interval as the key length
### Arc Diagram
A visualization where arcs connect positions in the ciphertext where the same sequence appears.
**How to interpret:**
* The x-axis represents character positions in the ciphertext (0 to text length)
* Colored dots mark where each repeated sequence occurs
* Arcs connect consecutive occurrences of the same sequence
* **Arc height corresponds to distance**—taller arcs mean larger gaps between occurrences
* Look for arcs of similar heights across different sequences; this suggests those distances share a common factor (the key length)
* Hover over arcs to see the exact sequence, positions, and distance
* Multiple short, similar-height arcs often indicate a short key length
### Key Length Analysis
A horizontal bar chart showing relative confidence scores for the top potential key lengths.
**How to interpret:**
* Each bar represents a potential key length
* Bar length shows relative confidence as a percentage (longest bar = 100%)
* **Higher percentages = stronger candidates**
* This view normalizes the factor frequencies, making it easier to compare relative strengths
* A key length with 100% confidence that's far ahead of others (e.g., next is 40%) is a strong indicator
* If multiple key lengths show similar confidence, they may be multiples of each other—the smallest is likely the actual key length
Note: since 2 is an extremely common factor, the tool does have a bias towards a key
length of 2. So keep this in mind.
### Distance Heatmap
A matrix showing the Greatest Common Divisor (GCD) relationships between pairs of distances.
**How to interpret:**
* Both axes list the unique distances found between repeated sequences
* Each cell shows the GCD of the two distances (row and column)
* **Brighter/lighter cells = higher GCD values = stronger common factors**
* The diagonal always shows each distance's GCD with itself (the distance value)
* Look for rows or columns with consistently bright cells—those distances share factors with many others
* A GCD value that appears frequently throughout the matrix is a strong key length candidate
* Hover over cells to see the exact calculation: GCD(distance₁, distance₂) = value
## Kasiski Settings
### Sequence Length Range
* **Minimum Length**: The shortest sequence to search for (default: 3 characters)
* **Maximum Length**: The longest sequence to search for (default: 20 characters)
Shorter sequences occur more frequently but may be coincidental. Longer sequences are more reliable indicators but occur less often.
### Max Results
Limits the number of sequences displayed. The tool prioritizes sequences by frequency (most common first) and length (longer sequences
preferred when counts are equal).
## Practical Application
The Kasiski examination is most effective when:
* The ciphertext is long enough to contain repeated sequences
* The cipher uses a repeating key (polyalphabetic substitution)
* The key length is relatively short compared to the message length
Once a likely key length is determined, the ciphertext can be divided into groups (every Nth character) and each group analyzed
separately using single-alphabet techniques like frequency analysis.
## Caveats
* Very short ciphertexts may not contain enough repeated sequences for reliable analysis
* Random coincidental matches can produce false positives, especially with short sequences
* Modern ciphers and properly implemented encryption are not vulnerable to this technique
* The analysis assumes the original text has natural language patterns; random or compressed data will not produce meaningful results
# Kolmogorov-Smirnov Test
Source: https://docs.cipherinspector.com/widgets/ks-test
The Kolmogorov-Smirnov test measures how closely a ciphertext character distribution matches a reference distribution.
## How it works
The Kolmogorov-Smirnov (K-S) test is a statistical method that compares two probability distributions by measuring the maximum vertical
distance between their cumulative distribution functions (CDFs).
The widget first counts the frequency of each character (or n-gram) in your ciphertext. This creates an observed distribution of
how often each character appears.
A reference distribution is selected based on your comparison mode:
* **Uniform**: Equal probability for all observed characters
* **English**: Standard English letter frequencies (e.g., E at 12.7%, T at 9.06%)
* **Ciphertext**: The character distribution from another ciphertext you select
Both the observed and reference distributions are converted into cumulative distribution functions. A CDF shows, for each
character, the total probability of that character and all characters before it.
The D-statistic is calculated as the maximum absolute difference between the two CDFs at any point. A smaller D-statistic
indicates the distributions are more similar.
The p-value represents the probability that the observed difference could occur by chance. Higher p-values suggest the
distributions match well; lower p-values indicate significant differences.
## Comparison Modes
### Uniform Distribution
Compares your ciphertext against a uniform distribution where every character has equal probability. This is useful for detecting whether
encryption has produced evenly distributed output.
### English Frequencies
Compares your ciphertext against standard English letter frequencies. Only alphabetic characters (A-Z) are analyzed. This helps identify
if text resembles natural English.
### Another Ciphertext
Compares your ciphertext against the character distribution of a selected base ciphertext. Useful for determining if two ciphertexts were
encrypted using similar methods or share statistical properties.
## Display Modes
### Score View
Displays a table with:
* **D-statistic**: The maximum difference between CDFs (0 to 1 scale)
* **P-value**: Statistical significance (color-coded for quick interpretation)
* **Interpretation**: Human-readable assessment of the result
* **Sample size**: Number of characters or n-grams analyzed
### CDF Graph View
Displays an interactive chart showing:
* **Solid lines**: Observed CDF from your ciphertext
* **Dashed lines**: Expected CDF from the reference distribution
* **Dotted vertical line**: Location of maximum difference (D-statistic)
## N-gram Settings
### N-gram Size
Instead of analyzing single characters, you can group characters into n-grams:
* **1**: Single characters (default)
* **2**: Bigrams (pairs like "TH", "HE")
* **3**: Trigrams (triplets like "THE", "AND")
Larger n-grams capture patterns in character sequences but require longer texts for meaningful analysis.
### N-gram Mode
* **Sliding Window**: Overlapping n-grams (ABCD → AB, BC, CD)
* **Block**: Non-overlapping n-grams (ABCD → AB, CD)
## P-Value Interpretation
| P-value Range | Interpretation |
| ------------- | ---------------------------- |
| > 0.10 | Distributions match well |
| 0.05 - 0.10 | Slight deviation |
| 0.01 - 0.05 | Significant deviation |
| \< 0.01 | Very different distributions |
## Practical Applications
The Kolmogorov-Smirnov test can be used to:
* Determine if ciphertext has uniform byte distribution (suggesting strong encryption)
* Identify if plaintext resembles natural English
* Compare multiple ciphertexts to detect similar encryption methods
* Analyze whether a substitution cipher preserves frequency patterns
## Caveats
* English frequency comparison only analyzes alphabetic characters; non-alphabetic characters are filtered out
* For n-gram sizes greater than 1, English frequency comparison falls back to uniform distribution (no reference English n-gram
frequencies available)
* Very short texts may produce unreliable p-values due to small sample sizes
* The test measures overall distribution similarity, not specific character mappings
# Levenshtein Distance
Source: https://docs.cipherinspector.com/widgets/levenshtein-distance
Measure the edit distance between two ciphertexts to quantify their similarity.
## How it works
The Levenshtein Distance widget calculates the minimum number of single-character edits (insertions, deletions, or substitutions)
required to transform one ciphertext into another. This metric is useful for comparing two ciphertexts and determining how similar or
different they are.
Choose a source ciphertext and a target ciphertext from your available ciphertexts. The widget will compare these two texts
character by character.
Levenshtein distance takes into consideration the settings for each ciphertext. These settings include:
* Ignore whitespace
* Ignore punctuation
* Ignore casing
* Genericize text
The comparison is performed after these preprocessing options are applied.
The algorithm computes the minimum edit distance using dynamic programming. For each position in both texts, it determines the
optimal sequence of operations needed to transform one text into the other.
The results can be viewed in two modes: Score view shows the numeric distance and similarity percentage, while Visual Diff view
highlights the specific character differences.
## Understanding the Results
### Distance Score
The distance score represents the minimum number of edits required:
* **0** means the texts are identical
* Higher numbers indicate more differences between the texts
### Similarity Percentage
The similarity percentage is calculated as:
$$
\text{Similarity} = \left(1 - \frac{\text{Distance}}{\text{Max Length}}\right) \times 100\%
$$
Where Max Length is the length of the longer text. This gives you an intuitive percentage:
* **100%** means identical texts
* **0%** means completely different texts (every character needs to be changed)
## Levenshtein Distance Settings
### Display Mode
#### Score View
Displays the edit distance as a prominent number along with:
* Similarity percentage with a color indicator (green for similar, red for different)
* Character counts for both source and target texts
* Labels showing which ciphertexts are being compared
#### Visual Diff View
Provides a character-by-character visualization of the differences:
* **Green background**: Characters that need to be inserted (present in target but not source)
* **Red background**: Characters that need to be deleted (present in source but not target)
* **Yellow/Blue highlight**: Characters that need to be substituted (different character in each text)
* **No highlight**: Matching characters
## Edit Operations
The Levenshtein algorithm considers three types of edits:
| Operation | Description | Example |
| ---------------- | ------------------- | --------------------------------------- |
| **Insertion** | Add a character | "cat" → "cart" (insert 'r') |
| **Deletion** | Remove a character | "cart" → "cat" (delete 'r') |
| **Substitution** | Replace a character | "cat" → "bat" (substitute 'c' with 'b') |
## Practical Applications
Levenshtein distance analysis can be leveraged to:
* **Detect minor variations**: Find ciphertexts that are nearly identical with small alterations
* **Identify related texts**: Determine if two ciphertexts may have originated from similar sources
* **Track modifications**: Understand what changes were made between two versions of encrypted content
* **Pattern matching**: Locate texts that approximate a known pattern despite small differences
## Interpretation Guide
| Similarity | Interpretation |
| ---------- | ------------------------------------------------------- |
| 90-100% | Nearly identical - minor differences only |
| 70-89% | Highly similar - same general content with some changes |
| 50-69% | Moderately similar - significant overlap exists |
| 25-49% | Low similarity - mostly different content |
| 0-24% | Very different - little to no common content |
## Caveats
* **Length sensitivity**: Very different text lengths will naturally result in higher distances due to the number of insertions or
deletions required.
* **Position matters**: Two texts with the same characters but in different orders will have a high distance.
* **Computational limits**: Very long texts may take longer to process due to the nature of the comparison algorithm.
* **Symmetric metric**: The distance from A to B equals the distance from B to A.
# Missing Characters
Source: https://docs.cipherinspector.com/widgets/missing-characters
Detect which characters from the expected character set are absent in the ciphertext.
## How it works
The Missing Characters widget analyzes your ciphertext to identify which characters from
the expected character set are not present. The expected character set depends on the
encoding type of your ciphertext.
Based on the ciphertext's encoding type, the widget identifies the expected
character set:
* **Text encodings** (UTF-8, ASCII, UTF-16, UTF-32, Latin1): Letters A-Z
* **Data encodings**: Characters specific to that encoding format
The widget scans the original ciphertext string, not the decoded bytes, to find
which characters from the expected set are present.
Characters that are not found in the ciphertext are reported as missing.
Optionally, present characters can also be displayed.
## Character Sets by Encoding
### Text Encodings
For text-based encodings (UTF-8, ASCII, UTF-16, UTF-32, Latin1), the widget checks for
the presence of letters A through Z. The check is case-insensitive, meaning both
uppercase and lowercase letters count toward the same character.
### Data Encodings
| Encoding | Expected Characters |
| ----------- | ---------------------------- |
| Binary | 0, 1 |
| Octal | 0, 1, 2, 3, 4, 5, 6, 7 |
| Decimal | 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 |
| Hexadecimal | 0-9, A-F (case-insensitive) |
| Base64 | A-Z, a-z, 0-9, +, / |
## Settings
### Show Present Characters
When enabled, the widget displays both missing characters (in red) and present
characters (in green). When disabled, only missing characters are shown.
## Practical Applications
The Missing Characters widget can be used to:
* **Identify substitution cipher constraints**: If certain letters never appear in a
ciphertext, they may have been deliberately avoided or mapped to other symbols
* **Detect encoding anomalies**: A hexadecimal string missing certain digits may
indicate a pattern or constraint in the original data
* **Verify data completeness**: Check if a Base64 or hex dump contains all expected
characters
* **Analyze cipher alphabets**: Determine if a cipher uses a reduced alphabet. For example, if one character is missing it may indicate a Playfair cipher that was then rotated, as Playfair traditionally replaces I/J.
## Caveats
* For text encodings, only letters A-Z are checked. Numbers, punctuation, and special
characters are not included in the analysis
* For data encodings, the analysis is performed on the encoded string itself, not the
decoded byte values
* Whitespace and formatting characters in the original text are ignored when determining
which encoding characters are present
# Normor
Source: https://docs.cipherinspector.com/widgets/normor
Normor measures how closely a ciphertext letter frequency order matches the standard English letter frequency order.
## How it works
Normor analyzes letter frequencies, so the character encoding of your input affects which characters are available for analysis.
Normor takes into consideration the settings for each ciphertext. These settings currently include:
* Ignore whitespace
* Ignore punctuation
* Ignore casing
* Genericize text
For data encodings (base64, hex, octal, decimal, etc.) the ciphertext is first decoded to Latin-1 before
the toggles are applied.
After preprocessing, the text is filtered to keep only alphabetic characters (A-Z). All other characters—numbers,
symbols, spaces, and extended characters—are removed. The remaining letters are converted to uppercase for
consistent analysis.
The widget tracks how many characters were filtered and displays a warning in the settings panel when
non-alphabetic characters are present.
Each of the 26 letters is counted. Letters that don't appear in the text receive a count of zero.
Letters are arranged from most frequent to least frequent. When two or more letters have the same count,
they are ordered alphabetically. This produces a 26-letter string representing the observed frequency order.
For example, if E appears 50 times, T appears 45 times, and A appears 40 times, the observed order would
begin with `ETA...`
The standard English letter frequency order is:
```
ETAOINSRHLDUCMGFYPWBVKXJZQ
```
For each letter A through Z, the algorithm finds:
* The letter's position in the observed order (0-25)
* The letter's position in the expected English order (0-25)
The absolute difference between these two positions is calculated for each letter.
The Normor score is the sum of all 26 position differences. A lower score indicates the ciphertext's
frequency pattern is closer to normal English.
```
Normor Score = Σ|observed_position(letter) - expected_position(letter)| for all letters A-Z
```
## Score Interpretation
| Score Range | Likely Cipher Type |
| ------------- | ------------------------------------------------------ |
| Below 60 | Near-perfect English frequency match |
| 60-99 | Transposition cipher or plaintext |
| Around 130 | Key phrase ciphers |
| Around 190 | Simple substitution ciphers |
| 220 and above | Aristocrat, Patristocrat, Gromark, or Phillips ciphers |
## Normor Settings
### Display Type
There are two display options for Normor.
#### Table
Shows a summary for each ciphertext including:
* The Normor score
* An interpretation of what cipher type the score suggests
* The total letter count after filtering
Ciphertexts that had non-alphabetic characters filtered are marked with an asterisk.
#### Graph
Displays a bar chart showing the position difference for each letter. The x-axis shows letters arranged in
standard English frequency order (E, T, A, O, I, N, S, R, H, L...). The y-axis shows how far each letter's
observed position differs from its expected position.
When analyzing multiple ciphertexts, each is shown as a grouped bar with its assigned color.
## Ciphertext Warnings
When a ciphertext contains non-alphabetic characters, a warning appears in the settings panel. The warning
lists each affected ciphertext with:
* The ciphertext name and color indicator
* The number of non-alphabetic characters that will be filtered
* The percentage of the total text those characters represent
A high percentage of filtered characters often indicates the ciphertext may be binary data rather than text,
which can produce misleading results.
## Practical Application
Normor can be leveraged to:
* Quickly classify ciphers by family. Transposition ciphers preserve letter frequencies and score low, while
substitution ciphers disrupt frequencies and score high.
* Detect plaintext. A very low score suggests the text may be unencrypted English or only lightly obscured.
* Compare multiple ciphertexts to identify which ones share similar encryption methods.
## Caveats
* **Short texts produce unreliable scores.** With fewer than 100-200 letters, natural variation can significantly
skew the frequency order. A short plaintext passage might score higher than expected simply due to unusual word choices.
* **Non-English plaintext skews results.** The expected frequency order is based on English. Text encrypted from
French, German, or other languages will have different baseline frequencies, making the score less meaningful.
* **Data encodings can produce misleading results.** When a Base64 or Hex string decodes to binary data rather
than text, some bytes will coincidentally fall in the A-Z range. The widget will analyze these "accidental letters,"
producing a score that doesn't reflect meaningful content.
* **Polyalphabetic ciphers flatten frequencies.** Ciphers like Vigenère use multiple substitution alphabets, which
tends to flatten letter frequencies toward uniformity. These may score differently than simple substitution ciphers
despite being in the same family.
* **Zero-count letters affect the score.** If a letter doesn't appear in the ciphertext, it still occupies a position
in the observed order (sorted alphabetically among other zero-count letters). This can inflate the score for short
texts where several letters are missing entirely.
## Further reading
* [Read the paper on Normor](https://www.ackgame.com/Normor%20Revisited.pdf)
# Shannon Entropy
Source: https://docs.cipherinspector.com/widgets/shannon-entropy
Shannon entropy is a measurement of the randomness of text.
## How it works
Shannon Entropy will be different based on the character encoding of your input.
For all data encodings, the data is first decoded to a `Uint8Array` and then converted to
a string based on its encoding type (ASCII, Latin1, UTF-8, UTF-16, UTF-32). This step takes precedence over any other ciphertext settings,
unless the widget evaluates the ciphertext bytes rather than the encoded text data.
Display encodings are
not decoded before analysis and are analyzed as-is, unless the widget is designed
to evaluate the ciphertext bytes.
Shannon Entropy takes into consideration the settings for each ciphertext. These settings currently include:
* Ignore whitespace
* Ignore punctuation
* Ignore casing
* Genericize text
For data encodings (base64, hex, octal, decimal, etc.) the ciphertext is first decoded to Latin-1 before
the toggles are applied.
After all of the above steps are performed, the Shannon entropy calculations are executed and displayed.
## Shannon Entropy formula
This widget uses the following formula for calculating shannon entropy:
```
H = -Σ p(x) * log₂(p(x))
```
[Read more](https://www.numberanalytics.com/blog/shannon-entropy-demystified-calculation-guide).
### Periodic Shannon Entropy formula
Periodic Shannon Entropy is different based on the mode.
#### N-gram mode: Block
For this mode, the process is:
1. Generate n-grams from the entire text.
2. Group n-grams based on the "sample rate" setting, where sample rate is the number of n-grams in the entropy calculation.
3. Calculate Shannon Entropy for each group using the basic Shannon Entropy formula.
#### N-gram mode: Sliding window
For this mode, the process is:
1. Slide a window of size ngramSize across the text and generate n-grams. This will contain overlapping n-grams.
2. Follow steps 2 and 3 above.
## Shannon Entropy Settings
### N-grams and sliding window vs. block analysis
Shannon Entropy can be performed on n-grams where `n >= 1`. For n-grams > 1, it is important
to understand the difference between sliding window and block analysis.
#### N-gram mode: Sliding window
Sliding window analysis "slides" across the ciphertext to create n-grams. For the text `Hello`:
```
He: 1
el: 1
ll: 1
lo: 1
```
Notice that characters at a given index will appear at least twice for n > 1.
#### N-gram mode: Block analysis
Block analysis evaluates your n-grams as non-overlapping chunks. For `Hello`:
```
He: 1
ll: 1
```
Notice that the final character, `o`, is not present. When using block analysis,
beware of missing data. The ciphertext length (*after all toggles are applied*)
must be divisible by your n-gram size for all characters to be represented in the
Shannon Entropy!
### Periodic entropy vs. Table
There are two display options for Shannon Entropy.
#### Periodic entropy (graph)
Shows a line chart, where each line is the periodic Shannon entropy of a ciphertext. The height
represents the entropy, and the horizontal axis represents how far into the ciphertext the
measurement is.
#### Table
Shows a table of values, with a single entropy value for each ciphertext. This is the entropy for the
entire ciphertext.
### Sample rate
The sample rate is used for the periodic analysis to determine how many n-grams to sample when calculating entropy. Generally,
a sample rate > 16 is recommended to start seeing patterns emerge.
## Practical Application
Shannon entropy can be leveraged to:
* Determine how close a ciphertext is to being random.
* See if a ciphertext is relatively close to English.
## Caveats
* Short text may not be sufficient in measuring entropy.
* This measurement only tells one part of the story. Combine with other tools to get a full picture.
# Title
Source: https://docs.cipherinspector.com/widgets/title
The title widget allows you to create a title/description block.
## Overview
The title widget helps you organize your dashboard into sections with a clear title and description.
## Settings
### Title
This is the title, which will display in large text.
### Description
This is the description, which will display under the title in smaller text.