To check a result after looking up an Elder Futhark character, open the Rune Meanings catalogue, search for the character you just consulted, and read its code point, transliteration, literal gloss, aett position, Unicode standard name, and uncertainty note on the matching row, confirming each field against the rune you intended. A "result" on this page is a verified historical-language reference, not a divination outcome: the catalogue draws no card, scores no reading, predicts nothing about money, health, romance, or career, and assigns no spiritual keyword to any rune, so what you are checking is whether the row you landed on actually matches the character, the conventional Unicode name, and the qualified scholarly gloss for that character. Treat each row as a small bundle of distinct claims with different sources, and the verification workflow is the act of reading that bundle against the rune you meant to look up. If anything in the row does not line up, the search did not reach the entry you wanted, and the right move is to refine the query, reset the catalogue, or filter to a specific aett before drawing any conclusion from the entry.
What a "result" means on this catalogue
On most rune websites a "result" means a divination message: a single drawn rune plus a paragraph of interpretation. The Rune Meanings page behaves differently by design. Its catalogue is a historical-language reference built on the encoded Elder Futhark character set, not a divination tool. The page returns no drawn rune, no predictive paragraph, and no score, so there is nothing to interpret in the spiritual sense. What it returns is a row of sourced facts about a specific encoded character, and "checking the result" means confirming that the row on screen belongs to the rune you wanted and not to a different one in the same aett or block.
This matters because the 24 Elder Futhark characters sit inside a larger Runic Unicode block, U+16A0 to U+16DF, that also contains later and variant forms. Two characters in that range can look almost identical and still be different code points, so the row's code point is the only field that uniquely identifies the entry. Confirmation also matters for the reconstructed literal glosses: labels such as cattle, gift, hail, ice, sun, horse, water, day, inheritance, and household are scholarly reconstructions from later Germanic rune-name traditions rather than contemporary Elder Futhark definitions. Checking the uncertainty note lets you see where the gloss is firm, where it is qualified, and where a row like Perthro simply has no broadly agreed literal gloss. The verification workflow is the act of treating each row as a claim that can be checked, not a message that can be obeyed.
The fields every rune row carries
Every row on the catalogue exposes a small bundle of text labels: the displayed character, its Unicode code point, the transliteration, the aett group and position within that group, the literal gloss, the Unicode standard name, and the uncertainty note. Each one answers a different question and each one has a different source authority, which is why they are checked together rather than individually. The character is the drawn rune glyph; the code point is the four-hex-digit Unicode identifier, for example U+16A0 for the first entry, Fehu. The transliteration is the conventional lowercase letter or pair, the aett group is one of the three conventional eight-rune groupings in the displayed sequence, the position is the slot from 1 to 8 within that aett, the literal gloss is the reconstructed English label, the Unicode standard name is the encoding label Unicode assigns to that code point, and the uncertainty note records what scholars disagree about for that specific entry.
Because the table maintains these labels as text rather than as decoration, the row stays usable on narrow screens, on font-fallback renders, and through keyboard navigation. If the system font cannot draw the Runic character, the Unicode code point and the uppercase Unicode standard name remain readable, and the literal search field will still find the entry by name. This is one of the practical reasons a check reads the row as a bundle: any single field can be invisible on a given device, but the others stay legible. Penn State's Germanic Runes reference documents this fallback behaviour for the broader Runic block, and the Rune Meanings implementation keeps the same fields visible by labelling each one with plain text alongside the character.
How to check a rune result step by step
- Open the Rune Meanings catalogue in a fresh browser tab so any prior filter state on the page cannot leak into the check.
- Type into the search box the character itself, a common name, a transliteration, a literal gloss word, or a Unicode code point such as 16A0; the box accepts any of these as a single literal query.
- If you know which of the three eight-rune groups the rune should belong to, pick that aett filter from the selector so only the eight candidate rows stay visible.
- Read the matching row field by field: compare the displayed glyph against the rune you intended, confirm the code point maps to an entry inside U+16A0–U+16DF, and read the transliteration, literal gloss, Unicode standard name, and uncertainty note on the same line.
- Cross-check the uncertainty note against the gloss; if the note says a gloss is disputed or has no broadly agreed form, treat the literal gloss as qualified rather than as a confirmed definition.
- If anything in the bundle does not line up, click Reset catalogue to restore all 24 entries and re-select the first row, then repeat the search with a different field to confirm the row you actually want.
- When the row, code point, transliteration, gloss, Unicode name, and uncertainty note all read consistently, the check is complete; close the check without storing anything, since the page does not save queries, filters, or selections.
Each step is a verification step, not a divination step. There is no point at which the catalogue flips the result into a reading, draws an additional rune, or asks for context about a personal question.
Separating Unicode encoding facts from reconstructed glosses
The table below separates the row fields by source authority so a check knows what kind of claim it is making when it confirms a field. Encoding facts come from Unicode's authoritative Runic NamesList and stay stable across renderers. Reconstructed glosses come from later Germanic rune-name traditions and modern scholarly conventions, so they vary by source and should be read with the row's uncertainty note attached.
| Field | What it shows | Source authority | How confident a check can be |
|---|---|---|---|
| Character | Encoded Runic glyph drawn on the row | Unicode Runic block | High: identical copies of the same character carry the same code point |
| Code point | Four-hex-digit identifier such as U+16A0 | Unicode standard | High: each character maps to one code point across compliant fonts |
| Transliteration | Conventional lowercase letter or pair, e.g. f, þ, ng | Scholarly convention | Medium: varies by scholarly tradition (for example j versus y, ng versus ŋ) |
| Aett and position | Group 1/2/3 and slot 1–8 in the displayed sequence | Conventional 24-rune table | High within the displayed layout; depends on which convention the table follows |
| Literal gloss | Reconstructed English label (cattle, gift, hail, and so on) | Later Germanic rune-name traditions | Low to medium: scholarly reconstruction, not a contemporary definition |
| Unicode standard name | Encoding label Unicode assigns to the code point | Unicode Runic NamesList | High as an encoding label; not proof of the word every ancient runewriter used |
| Uncertainty note | Per-row note about disputed gloss, sound, or naming | Selected scholarly references | High as a documented caveat: read it before generalising from the gloss |
The reason the uncertainty note sits beside the gloss rather than after the catalogue is that the note changes what the gloss is allowed to mean on that specific row. On rows where the note says no broadly agreed literal gloss exists (Pertho is the canonical example), the gloss field is left unqualified and a check should not pretend a firm definition has been confirmed.
Reading the uncertainty note so a check is not over-claimed
The uncertainty note is the most commonly skipped field during a quick check, and that is exactly where over-claims creep in. On Perthro the note states that there is no broadly agreed literal gloss, so "the rune Perthro means X" is not a finding the catalogue supports. On Algiz the note records disputed name history, sound history, and meaning; the elk comparison is treated as a common but qualified parallel rather than as a settled etymology. On Kauna or Kenaz the catalogue shows the qualified boil or ulcer gloss used by the selected independent table, so a check should not promote it to "the rune Kenaz means torch." On Eihwaz the transliteration varies by scholarly convention, and on Laguz or Laukaz the vocalization varies too. Where the Wikipedia summary of the Elder Futhark table and the catalogue disagree on a minor detail, the page defers to the labelled convention rather than guessing, so an honest check defers as well.
This is also where a useful follow-up read sits. If you want to compare the displayed reconstruction against alternatives, the article on whether Elder Futhark rune meanings are ancient definitions documents exactly that boundary, and the piece on avoiding mistakes with Elder Futhark rune meanings covers the same caveats in checklist form.
If a check does not line up, what to do next
A failed check has only a handful of causes on this catalogue, and each one has a single fix. The character glyph renders but the code point is empty or missing: clear the search, type the code point directly into the box, and the matching row surfaces because the search field accepts literal code points as a query. The search returns the wrong aett: open the aett filter, pick the correct group of eight, and the row list narrows to candidates only. The literal gloss contradicts what you read elsewhere: read the row's uncertainty note before concluding the gloss is wrong, because most contradictions trace back to scholarly convention rather than to a catalogue error. The page seems to remember an old filter or selection: click Reset catalogue to restore all 24 entries and re-select the first row, then start the check from a clean state. Throughout this debugging, the catalogue does not store the search, the filter, the selection, or the reset action anywhere; resetting is a browser-memory operation only, which is why a stale check never leaks into the next one.