Introduction

The best way to limit the length of an EditText in Android is usually not a custom TextWatcher. The normal solution is an InputFilter.LengthFilter, because it enforces the limit at the input layer instead of letting the user enter extra text and trimming it afterward.

The Simple XML Option

If the limit is static, the easiest approach is the XML attribute.

1<EditText
2    android:id="@+id/edit_text"
3    android:layout_width="match_parent"
4    android:layout_height="wrap_content"
5    android:maxLength="10" />

This is concise, declarative, and easy to understand in layout code.

The Programmatic Option

If the limit must be set dynamically, use an input filter programmatically.

1EditText editText = findViewById(R.id.edit_text);
2editText.setFilters(new InputFilter[] {
3    new InputFilter.LengthFilter(10)
4});

This is the preferred runtime approach because it behaves the same way as the XML limit and still works at the input-filter level.

Why TextWatcher Is Usually Not the Best Tool

A TextWatcher can observe text changes, but using it to cut text back after the user types too much is usually clumsier.

1editText.addTextChangedListener(new TextWatcher() {
2    @Override public void beforeTextChanged(CharSequence s, int start, int count, int after) {}
3    @Override public void onTextChanged(CharSequence s, int start, int before, int count) {}
4    @Override public void afterTextChanged(Editable s) {
5        if (s.length() > 10) {
6            s.delete(10, s.length());
7        }
8    }
9});

This can work, but it is more fragile. Cursor position, recursion concerns, and user experience all become harder to manage than with a proper input filter.

TextWatcher is better for reacting to input, not for basic length enforcement.

When a Custom Filter Makes Sense

If the rule is more complicated than a simple maximum length, write a custom InputFilter. For example, you may want a limit that depends on the type of characters being entered.

1public class LettersOnlyLengthFilter implements InputFilter {
2    private final int maxLetters;
3
4    public LettersOnlyLengthFilter(int maxLetters) {
5        this.maxLetters = maxLetters;
6    }
7
8    @Override
9    public CharSequence filter(CharSequence source, int start, int end,
10                               Spanned dest, int dstart, int dend) {
11        int currentLetters = 0;
12        for (int i = 0; i < dest.length(); i++) {
13            if (Character.isLetter(dest.charAt(i))) currentLetters++;
14        }
15        for (int i = start; i < end; i++) {
16            if (Character.isLetter(source.charAt(i)) && currentLetters >= maxLetters) {
17                return "";
18            }
19            if (Character.isLetter(source.charAt(i))) currentLetters++;
20        }
21        return null;
22    }
23}

That is more powerful than maxLength, but you should only go there when a simple length filter is not enough.

In other words, start with the built-in filter and only move to custom logic when the requirement is genuinely more than “cap the number of characters.” That keeps the input stack predictable and avoids surprising editing behavior.

It also reduces the amount of code you need to maintain around basic text entry.

Common Pitfalls

• Using TextWatcher for basic length limiting when an input filter is simpler and more robust.
• Forgetting that XML android:maxLength already solves many static cases.
• Truncating text after the fact and creating a jarring cursor or editing experience.
• Writing a custom filter when a standard LengthFilter already handles the requirement.
• Treating validation and input filtering as the same thing when they serve different roles.

Summary

• Use android:maxLength in XML for simple static limits.
• Use InputFilter.LengthFilter for dynamic runtime limits.
• Prefer input filters over TextWatcher for basic length enforcement.
• Reach for custom filters only when the rule is more complex than a fixed maximum.
• The best solution is the one that blocks invalid input cleanly instead of repairing it later.