Reading
Reading time calculator
Minutes per section, Markdown-aware, code left out.
Free tool
Markdown diff checker
Paste two versions of a lesson and see what changed, paragraph by paragraph, with the changed words highlighted. Then check that the edit kept every heading, code block, link and image.
Free, no sign-up. Nothing you type leaves your browser.
Two versions of a lesson
Words changed
13% +26 / −20 words
Before: 16 blocks · After: 18 blocks
3paragraphs changed
2added
0removed
13unchanged
What the edit kept
- Kept all 5 headings
- Kept all 3 code blocks
- Removed 1 link
- +6 words (3% longer)
Paragraph by paragraph
- # Connect to GitHub with SSH
- ChangedBeforeSSH keys let you push to GitHub without typing
yourpasswordeverytime. You'llmakea key on your laptop and give GitHub the public half.AfterSSH keys let you push to GitHub without typing a password each time. You'll create a key pair on your laptop and give GitHub only the public half. - ## Before you start
- ```bash ssh-keygen -t ed25519 -C "you@example.com" ```
- ChangedBeforePress Enter to accept the default file location. When it asks for a passphrase, choose one you'll remember.
The passphrase protects the key if someone copies the files on your laptop.AfterPress Enter to accept the default file location. When it asks for a passphrase, choose one you'll remember. - AddedStart the SSH agent and add your key to it, so you only type the passphrase once:
- Added```bash eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_ed25519 ```
- ## Add the key to GitHub
- The first time, SSH asks whether you trust github.com. Type yes. You should see a greeting with your username.
- ChangedBeforeIf it says "Permission denied", the key wasn't added.
Read the [GitHub guide](https://docs.github.com/en/authentication)and try again.AfterIf it says "Permission denied", the key wasn't added. Follow [GitHub's troubleshooting guide](https://docs.github.com/en/authentication/troubleshooting-ssh) and try again.
How to use the diff checker
- Paste the version learners have now under “Before” and the revised one under “After”. If you get them the wrong way round, swap them.
- Read the numbers. How many paragraphs changed, were added or removed, and what share of the words changed.
- Read the checks. Green means the headings, code blocks, links and images came through. Amber means something to look at.
- Read the diff. Removed blocks are red, added blocks are blue, and an edited paragraph shows both versions with the changed words marked. Long runs of unchanged paragraphs are folded; open them if you need the context.
- Copy what you need. The summary is a short note for a review or a changelog; the changes come as a
diffblock for a pull request or a message.
Why compare paragraphs, not lines
Tools like git diff compare lines. That suits code, where a line is usually one statement. Prose doesn’t work that way. In Markdown a paragraph is often a single long line, so one changed word marks the whole paragraph as replaced and you hunt for the difference yourself. If an editor re-wraps the text, every line after the edit changes even though the words didn’t.
This checker compares what a reader reads: whole paragraphs, headings, list blocks and code blocks. Spacing and line breaks inside a block are ignored, so re-wrapping isn’t a change. When a paragraph was edited rather than replaced, because the two versions share enough of their words in the same order, it shows as one change with the removed and added words highlighted. Unrelated paragraphs show as one removed and one added.
How the checks work
Each check compares the two versions directly. Headings are compared by their text, so a reworded heading counts as changed. Code blocks must match exactly, apart from spacing. Links and images are compared by address, and each one is counted, so a link that appeared twice must still appear twice. Length is counted in words outside code blocks. The share of changed words at the top is counted the same way, so a long code example doesn’t drown out the prose.
What to check after an edit, or an AI revision
- Headings. Learners find their way by them, and links to a section usually depend on its heading. A renamed heading can quietly break those links.
- Code. One changed character can break a command. Unless you meant to change it, code should come through untouched. If it changed, run it.
- Links and images. A changed address might be a better page, a broken one, or one that never existed: AI tools can produce addresses that look right and lead nowhere. Open every changed link.
- Length. The length check turns amber when the text grows or shrinks by more than a quarter. At that point it’s a different lesson, and the reading time and exercises may need to change with it.
- Meaning. Read each changed paragraph as a learner would. Did the step that tells them how to check their work survive? Are terms used the same way as in the rest of the course?
A worked example
The example in the checker is an SSH lesson from a programming bootcamp, revised four ways: an intro paragraph reworded, a sentence removed, a new step added, and a link changed. The result:
| What | Result |
|---|---|
| Paragraphs | 3 changed, 2 added (the new step and its code), 0 removed, 13 unchanged |
| Words | 13% changed: 26 added, 20 removed |
| Headings and code | All 5 headings and all 3 code blocks kept |
| Links | 1 removed |
| Length | 6 words longer (3%) |
The one warning is the link. Here it was intended: the new address goes to GitHub’s troubleshooting page, which is more useful at that point in the lesson. But the checker can’t tell a better link from a broken one, so this is the change to open before publishing. The removed sentence deserves a second look too. It explained what the passphrase protects; without it, the step is an instruction with no reason given.
Tips
- Compare with what learners have now, not with your last draft. That’s the change they will notice.
- Keep each revision to one purpose. A small, focused edit gives a diff you can read in a minute and approve with confidence.
- Check the rewritten sections for readability. Rewording can make a paragraph longer and harder without anyone meaning to. The lesson readability checker scores each section.
- Keep the summary. Pasted into a changelog, it tells the next person who edits the lesson what changed and why.
Questions people ask
How do I compare two Markdown files?
Paste the old version on the left and the new one on the right. The checker splits both into paragraphs, headings, lists and code blocks, shows which were changed, added or removed, and highlights the changed words inside each edited paragraph.
What is the difference between a line diff and a paragraph diff?
A line diff, like git diff, compares line by line, which suits code. In prose a paragraph is often one long line, so one changed word marks the whole line, and re-wrapping marks every line. A paragraph diff compares the units a reader reads and shows the words that changed.
Can I compare plain text, not just Markdown?
Yes. Plain text is split into paragraphs at blank lines and compared the same way. The checks for headings, code, links and images simply have less to report.
Why does a changed link show as removed?
The link check compares addresses. If an address changed, the old one is no longer in the text, so it counts as removed even when the link text stayed the same. That’s deliberate: a changed address is the edit most worth opening.
How do I check an AI rewrite of my lesson before publishing it?
Compare it with the version your learners have now. Read every changed paragraph, make sure each warning in the checks is a change you wanted, run any code that changed, and open every changed link.
Is my text uploaded anywhere?
No. The comparison runs in your browser; nothing you paste is sent to a server or saved.
Do this for every lesson, every group
Chalkenso is where courses are designed and improved: instructors note what happened on the exact passage, learners say where they got stuck, and AI drafts the next version for you to approve.