How accurate is this translator?

The engine

liblouis, an open-source braille translation library, does the translating. We didn't write it. Every translation on this site comes from liblouis 3.39.0 with its unmodified en-ueb-g1.ctb and en-ueb-g2.ctb tables. According to the liblouis README, it is also the braille translator inside the open-source screen readers NVDA and Orca. Grade 2 uses en-ueb-g2.ctb and Grade 1 uses en-ueb-g1.ctb.

Your browser runs liblouis compiled to WebAssembly, in a background thread (a Web Worker). Our build runs the same file to draw the braille examples on these pages, so the examples and the live tool can't disagree.

We don't change what the engine returns. Our code splits your text into lines, hands each line to liblouis, joins the cells it gets back, and lists any character the tables can't spell. It doesn't tidy, correct or reorder the braille.

Building and pinning the engine

A build script downloads the liblouis 3.39.0 release, stops if the file's SHA-256 hash differs from the one recorded below, and compiles it with Emscripten 6.0.10. The script copies the table files from the release unchanged. The file names below are the ones your browser loads.

Rebuilding gives the same files

When the build script ran again from scratch on September 27, 2026, all 11 files came out byte for byte the same as the ones listed above: the engine, its loader and the 9 table files.

Engine log

We stay on this liblouis release. Moving to a new one means running the corpus below against it first. This log dates each change of engine.

• September 26, 2026: first build, liblouis 3.39.0 with Emscripten 6.0.10. The corpus results come from this build.

The credits page covers the licences for all of this.

The test corpus

The corpus is 249 short inputs in 19 groups: cases other online translators get wrong, and cases the UEB rules treat in a special way. A script translates each input in Grade 2 and in Grade 1, and decodes the Grade 2 braille back to text.

We store the results. The test suite runs every input again and fails if a single cell differs from the stored result. That checks our side of the work: splitting lines, passing text in and out of the engine, and listing unsupported characters. It also shows at once what changes when we upgrade liblouis.

The stored results are the engine's own output from September 26, 2026. They show what the engine does. Until someone checks them against the ICEB rules, no transcriber has approved them.

The common-words check

A second check uses ordinary words: 10,714 common English words from the two smallest sizes (10 and 20) of Kevin Atkinson's SCOWL word lists. The list leaves out proper names, abbreviations and possessives. The credits page has its licence notice.

A script translates each word in Grade 2 and in Grade 1, converts both results to Braille ASCII and back, and decodes the braille back to text. As with the corpus, we store the results, and the test suite fails if any of them changes.

No word came back different, in either grade. Every word had braille in both grades, and none contained a character the tables cannot spell. For 7,536 of the words, the Grade 2 braille differs from the Grade 1 braille.

What this check shows

Our code passes each word to the engine and back without losing or changing anything. Braille ASCII converts back to the same cells, and the decoder reads the engine's braille for each word back as that word. The words are single, lower case and out of context. The corpus above covers capitals, numbers, punctuation and the rules that depend on neighbouring words.

Checked against a second build of liblouis

All 32,889 results matched a build of liblouis made by the liblouis project, so the way we compile liblouis didn't change its output for these inputs.

On September 27, 2026, a test script ran the same inputs through the automatic JavaScript build in the project's js-build repository: commit a694d1d947 of September 3, 2026, file build-no-tables-utf32.js. That build comes from an older Emscripten, as JavaScript rather than WebAssembly, and also uses 32-bit characters. We ran it as a test on our own computer only. This site never loads it and doesn't use its code.

Checked against the rulebook's examples

The liblouis project keeps test files for its UEB tables. Most of en-ueb.yaml is the worked examples of The Rules of Unified English Braille (2013 edition), and the project marks each example its tables are known to get wrong. (engine)

Each time we build the site, those files run through the same code your browser runs. Of the 2,126rulebook examples we can run, the engine writes 1,897 exactly as the rulebook does and 229 differently. The liblouis project already marks every one of the 229 as a known failure, so none of them comes from our build or our code. 122 more examples need italic or bold in the input. Our translator doesn't take those, so we don't run them.

With the project's other UEB test files, which include a list of more than 100,000 words, the check runs 219,148 translations and decodings. Every one the project expects to pass passes here. The 398 that differ are all on the project's list of known failures. You can download the full results as conformance.json.

96 of the 229 rulebook examples are about dividing a word at the end of a braille line, which this translator never does. The ones below matter for everyday text.

What the round-trip check shows

A matching round trip shows that the decoded text is one reading of the braille that the engine would write the same way. It does not show that the braille was correct UEB to begin with, or that the decoded text is what the writer typed.

The decoder turns braille into text, translates that text back into braille, and compares the two sets of cells. Where they differ, it marks the cells, because the decoding there is uncertain.

Known limitations

These are the places where the corpus shows the engine's braille, or the decoder's reading, can be wrong.

Apostrophes and single quotation marks

UEB writes the apostrophe as ⠄ (dot 3), a different sign from the single quotation marks ⠠⠦ and ⠠⠴. (ICEB 7.6.2, 7.6.6)

Print often uses the same mark for an apostrophe and a single quotation mark, so ICEB accepts that software cannot always choose between them correctly without a transcriber. Where nothing better is available, it may decide by whether there are letters on each side of the mark. (ICEB 7.6.13–7.6.15)

The engine decides from the print character and where it sits. In the corpus a straight apostrophe gives ⠄ every time. A curly right single quotation mark gives ⠄ inside a word and after most words, as in “don’t” and “Jones’”, but at the start of a word, and around the single letter in “rock ’n’ roll”, it becomes the closing quotation mark ⠠⠴. ICEB's examples of the apostrophe ⠄ include “rock ’n’ roll”, where both marks are apostrophes, and “the '90s”. (ICEB 7.6.6)

If you know a mark is an apostrophe, type the straight ' before translating.

Abbreviations in capitals

The rules prefer to spell out an acronym whose letters are said one by one, such as US for United States, and to contract it when in doubt. The engine cannot know how a word is said, so it contracts: US becomes ⠠⠠⠥, the capitalised wordsign for “us”, where the rulebook writes ⠠⠠⠥⠎. The table of rulebook examples has more.

One sign for every dash

UEB writes a print dash as ⠠⠤. The long dash ⠐⠠⠤ is used only when the print uses both a short and a long dash. (ICEB 7.2, 7.2.4)

The engine writes ⠠⠤ for both the en dash and the em dash and decodes ⠠⠤ as an em dash, so the braille does not record whether the print dash was short or long. It also writes ⠠⠤ for both when a text uses both lengths: “a – b — c” gives ⠁⠀⠠⠤⠀⠰⠃⠀⠠⠤⠀⠰⠉, where the rule above calls for the long dash on the longer one.

Some braille has more than one reading

A quotation mark standing alone reads as a wordsign: ⠦ as his, ⠴ as was, ⠠⠦ as His and ⠠⠴ as Was. (ICEB 7.6.8, 7.6.10)

The decoder takes one reading and cannot know the others. In the corpus, “e.g.” decodes as “e.go.”, “LLC” as “Llc”, and the capitalised passage “WHAT IS THIS” as “What is this”. Curly quotation marks and apostrophes come back straight. The round-trip check flags some of these and misses others.

No formatting

The translator produces a run of cells. It does not lay out pages, headings, lists, tables or page numbers. The BRF download is Braille ASCII at 40 cells to a line and 25 lines to a page, and nothing more.

Literary English only

The headers of en-ueb-g1.ctb and en-ueb-g2.ctb describe them as literary tables for Unified English Braille, uncontracted and contracted. Mathematics, science and computer notation, Nemeth Code, music braille and other languages are out of scope, and this page does not test them.

Characters without a UEB spelling

When its tables have no braille for a character, liblouis 3.39.0 does not drop it: it writes the character's code point as a run of escape cells, some of them eight-dot cells. The translator lists each one under the output with its code point. The corpus found these:

Published braille needs a transcriber

No certified transcriber has proofread anything on this site. We don't transcribe material for publication, signage, legal use or exams. That work needs a qualified transcriber and a proofreader working from the full rules.

ICEB offers the Rules of Unified English Braille as free electronic files that may be printed or embossed for personal use, on its UEB publications page. If a result matters, check it there.

Report a case

If a translation looks wrong, email us at support@uebtranslator.com. Send the text, the grade, the braille you got, what you expected, and the ICEB rule if you know it. Our contact page has the details.