License key formats: how to design secure, readable keys with keymask profiles

A license key is the one part of your licensing system every customer sees. They copy it from an email, paste it into your app, read it out to support and sometimes type it by hand from a screenshot. A good license key format makes all of that easy while staying impossible to guess. A bad one produces typos and support tickets and, at worst, keys someone else can generate.

This guide covers the decisions behind a key format: how much randomness a key needs, how to group characters so people can read them, which characters to leave out, how to use fixed prefixes, and how keymask profiles in qPapel Auth keep the format consistent across every product you sell.

What makes a good license key format?

A license key format has four jobs, and they pull in different directions.

• –Unguessable. Nobody should be able to produce a valid key by trying combinations or spotting a pattern.
• –Readable. Customers should be able to copy, type and read the key aloud without mistakes.
• –Identifiable. You and your support team should be able to tell at a glance which product or edition a key belongs to.
• –Meaningless. The key shouldn't encode anything an attacker could use, such as an order number, a date or a customer's email address.

The last point is where many older schemes went wrong. Keys validated by an algorithm inside the client, where certain characters must satisfy a formula, can be reverse-engineered into a key generator. Once someone extracts the formula, they can produce unlimited valid keys, and no ban list can keep up. A modern key is simply a random identifier, and whether it is valid is decided by looking it up on the server.

How much entropy does a license key need?

Entropy measures how unpredictable something is, in bits. For a key built from randomly chosen characters it is easy to calculate: multiply the number of random characters by log2 of the alphabet size. A 32-character alphabet gives exactly 5 bits per character, so 16 random characters give 80 bits.

How much is enough? For keys validated online, around 80 bits is already far beyond what guessing can reach. There are 2⁸⁰, roughly 1.2 × 10²⁴, possible keys. Even with a million keys issued, a single random guess has about a one in 10¹⁸ chance of matching a real one, and every guess is a request your server can rate-limit and log.

128 bits is the comfortable choice if you want headroom, if keys might ever be checked without a server, or if you simply want the margin used for cryptographic tokens. With Crockford Base32 it costs ten more characters than 80 bits. Anywhere between the two is a sound choice for most products. Two rules matter more than the exact number:

• –Use a cryptographically secure random generator. rand(), System.Random or anything seeded with the time can be predicted. Use your platform's secure generator, such as RandomNumberGenerator in .NET.
• –Count only the random part. A fixed prefix, separators, a checksum character or a sequence number add nothing to entropy. Calculate from the random characters alone.

// Illustrative: build a key body from Crockford Base32 with a secure RNG.
using System.Linq;
using System.Security.Cryptography;

static class KeyFormat
{
    const string Alphabet = "0123456789ABCDEFGHJKMNPQRSTVWXYZ"; // no I, L, O, U

    public static string NewKeyBody(int length = 16, int group = 4)
    {
        var chars = new char[length];
        for (int i = 0; i < length; i++)
            chars[i] = Alphabet[RandomNumberGenerator.GetInt32(Alphabet.Length)];

        return string.Join("-", Enumerable.Range(0, length / group)
            .Select(g => new string(chars, g * group, group)));
    }
}

// KeyFormat.NewKeyBody() returns something like "7KQ2-M9XD-4TPR-H6WN" (80 bits)

How to make license keys easy to read and type

Group characters in fours or fives

People read and check short chunks far more reliably than long strings, which is why phone and card numbers are grouped. Keys are no different. 7KQ2M9XD4TPRH6WN and 7KQ2-M9XD-4TPR-H6WN hold the same 80 bits, but the second is much easier to compare against an email or read over a call.

• –Use groups of four or five characters separated by hyphens.
• –Use one case only, normally uppercase, and treat input as case-insensitive.
• –Strip spaces and hyphens before validating, so a pasted key with stray whitespace still works.
• –Show keys in a monospaced font wherever customers see them, from the delivery email to your app's activation screen.

Leave out characters that look alike

Some characters are easy to confuse in common fonts, in low-resolution screenshots or when read aloud. Each confusion is a failed activation and, often, a ticket.

Crockford Base32 is a well-tested starting point: the digits plus uppercase letters without I, L, O and U, the last dropped to avoid accidental words. It keeps 32 symbols, so each character is still exactly 5 bits. Every extra character you remove costs a little entropy, which you win back with one more character in the key.

Fixed prefixes: label the key without weakening it

A fixed prefix is a short, constant label at the start of every key, such as PRO-, TEAM- or TRIAL-. It does nothing for security, but it helps the people who handle keys every day.

• –Support can identify a key instantly. A customer pastes a key into a ticket and you know the product and edition before looking anything up.
• –Customers can tell keys apart. Someone who owns two of your products, or a trial and a full license, knows which key is which.
• –Reports stay readable. A prefix per product or edition makes keys easy to recognise in exports, logs and spreadsheets from resellers.

Treat the prefix as public. It adds zero entropy, so the random part must be long enough on its own, and it must never decide anything. A key that starts with PRO- is a Pro key because the server record says so, not because of its first four characters. Keep personal or sequential data out of keys entirely: an order number or date tells an attacker how many keys exist and when they were made.

Example license key formats compared

Most products can choose from a small set of proven patterns. In the table, each X is one random character from Crockford Base32 unless stated otherwise.

Two patterns cover most cases. If customers type keys, use four groups of four Base32 characters, with a prefix where it helps. If keys are only ever pasted or passed between systems, readability matters less and a longer key costs nothing. Trial keys deserve their own prefix, because they are the keys support sees most; subscription licensing for software covers how trials fit alongside paid terms.

Keymask profiles in qPapel Auth

A keymask is the template a key generator follows: which positions are random, which characters are fixed and where the separators go. Setting it up by hand for every batch is how formats drift, with one product's keys in fours, another's in fives and a prefix forgotten halfway through a launch.

Custom Keymask Profiles, added to qPapel Auth in Changelog V6.5, fix that. You create a keymask once and save it as a profile, set a fixed prefix that is reused whenever you generate keys with it, and switch between saved profiles without configuring the keymask every time. Alongside the format, qPapel Auth lets you configure time periods and activation limits for the keys you generate.

1. 01

   Decide the format for each product

   Pick an alphabet, length and grouping using the tables above. Add a prefix if you sell several products, editions or trial keys.

2. 02

   Save it as a profile

   Create a custom keymask profile with your fixed prefix, and name it after the product or edition it belongs to.

3. 03

   Generate keys from the profile

   Select the saved profile whenever you generate keys, whether for a launch, a giveaway or a manual grant, instead of retyping the mask.

4. 04

   Keep validation on the server

   Keys are checked on PapelShip's servers, bound to the buyer's hardware on first activation and can be paused or banned at any time, whatever their format.

Changing a profile changes how new keys look; the keys you have already issued are separate records on the server. That makes it practical to tidy up a format for a new major version without asking existing customers to do anything. Delivery is a separate step: on PapelShip, a paid order generates its key and delivers it on screen and by email, as described in how to sell software licenses online.

Common license key format mistakes

• –Algorithmic keys checked in the client. If your app can tell a valid key from an invalid one offline, the rule can be extracted and turned into a key generator.
• –Counting the prefix as security. A 24-character key with a 12-character prefix has only 12 random characters, and only those count.
• –Predictable generators. Keys from a time-seeded or non-cryptographic random generator can be reproduced by anyone who knows roughly when they were made.
• –Meaningful content. Order numbers, dates or email addresses inside keys leak business data and make keys partly predictable.
• –Case-sensitive validation. Mixed-case keys pack more entropy into each character but cause typos. If you use them, never make customers type them.
• –Rejecting harmless input. Failing a key because of a trailing space or a missing hyphen creates tickets for no security gain.
• –A different format for every batch. Inconsistent formats slow support down and make mistakes more likely. Save the format once and reuse it.

A format is only one part of handling keys well. Generation, delivery, bans and leak response are covered in secure license key management, and binding keys to a machine in what is HWID locking. For plans and the full licensing feature set, see qPapel Auth.

Design the format once, then stop thinking about it

A good license key format is a small decision with a long tail. Choose enough random characters from a clean alphabet, group them so people can read them, add a prefix if it helps support, and keep everything that matters on the server. Then save it as a profile, so every key for that product follows the same rules without anyone having to remember them.

Once the format is settled, your attention can go where it does more good: delivering keys the moment payment confirms, binding them to hardware and acting quickly when one leaks.