Input masks for postcodes and phone numbers in Base by Zaweba

Typed data is messy in predictable ways. One person enters a postcode in lower case with no space, another adds two spaces, a third swaps the letter O for a zero. When you later search or sort, those records drift apart. An input mask on a text field in Base by Zaweba fixes this at the moment of typing, by forcing a pattern and tidying what is entered so it is always stored the same way.

The best example is the postcode. With the postcode mask on, someone can type sw1a1aa and Base saves it as SW1A 1AA. Nobody has to think about capitals or spacing, and every postcode in the table looks alike.

The ready-made UK masks

Base comes with masks for the formats British records use most: postcode, phone number, National Insurance number, sort code, time and car registration. Pick one in the table designer and the field follows it straight away. For most databases these cover the fields where people make the most typing slips, so start with them before writing your own.

They are a good fit for membership lists, customer tables, staff records and vehicle logs, where the same kinds of number come up again and again and need to match exactly when you search for them.

Writing your own mask

When none of the ready-made masks fits, you can write one with a small set of characters. A 0 stands for a digit that must be typed. A 9 is a digit that may be left out. L is a letter, and A is a letter or a digit. A > turns what follows into capitals, and a \ makes the next character literal, so it appears in the value exactly as written.

Build a mask by writing out a sample value and replacing each character with the symbol for what may go there. A stock code of two capital letters and four digits becomes >LL0000. If the code always has a fixed letter or punctuation mark in it, put a \ in front of that character so the mask treats it as part of the pattern rather than as a symbol.

Test a new mask on a few real values before you rely on it, especially ones you know are awkward. The aim is to stop mistakes without stopping genuine entries.

Masks on forms and on the website

A mask belongs to the field, so it works wherever the field is typed into: the datasheet and every form you design. When you export the database as a website, the exported site applies the same mask, so people entering records in a browser get the same help and the same tidy results as you do on your PC.

That consistency is the real gain. Search, sorting, duplicate checks and lookups all work better when the values are stored one way.

Masks, rules and lists together

A mask controls the shape of a value; it doesn't know whether the value is real. A correctly shaped postcode can still be the wrong one. Where you need a limit on the value itself, add a validation rule as well. Where the field should hold one of a few fixed choices, a value list with a dropdown usually suits people better than a mask.

Don't put masks on fields that genuinely vary. International phone numbers, overseas postcodes and free text names don't fit one pattern, and a strict mask there just pushes people to type something false. Use masks where the format is fixed and known, and let the rest stay free.