Categorical Encoding Methods: One-Hot vs Label vs Target

A model can’t read the word “red” or “blue.” Categorical encoding methods turn category labels into numbers a model can actually use, and the method you pick changes what the model is able to learn from that column.

One-hot encoding: safe, but grows fast

One-hot encoding creates a separate binary column for each category. It makes no assumption about order between categories, which is correct for something like color or country. The downside shows up with high-cardinality columns. A column with five hundred distinct values turns into five hundred new columns, most of them sparse.

Label encoding: compact, but implies an order that may not exist

Label encoding assigns each category a single integer. It’s compact and fast, but it quietly implies an ordering, since the model sees 3 as greater than 1. For genuinely ordinal categories, like a satisfaction rating from low to high, that’s appropriate. For something like a product category, it introduces a false relationship the model may pick up on without any real justification.

Target encoding: powerful, but leakage-prone

Target encoding replaces each category with a statistic of the target variable for that category, like the mean outcome. It can capture a lot of signal, especially for high-cardinality columns where one-hot would be impractical. It’s also the encoding method most prone to data leakage, since computing the target mean using the full dataset, including the rows you’re about to predict, leaks the answer directly into the feature. It has to be computed on training data only, usually with cross-validation folds to avoid a category overfitting to its own rows.

A real example: categorical features in a real warehouse

The Olist e-commerce analytics engineering project models real categorical dimensions like product category and seller across 99,441 orders. At the warehouse and dashboard level, these stay as readable text for exploration. The moment any of them feed a predictive model instead of a dashboard, the same one-hot versus target-encoding tradeoff applies, especially since product category in a real marketplace dataset like this tends to have high cardinality.

Choosing based on the model, not just the column

• Linear models and neural networks generally need one-hot or target encoding, since they can’t handle label encoding’s implied order for non-ordinal categories.
• Tree-based models can sometimes use label encoding reasonably well, since a tree can split around an arbitrary integer boundary without truly assuming linear order.
• High-cardinality columns push toward target encoding or hashing tricks, since one-hot becomes impractical past a few dozen categories.

A quick checklist

1. Does the category have a genuine order, or would label encoding introduce a false one?
2. How many distinct values does the column have, and would one-hot encoding create too many sparse columns?
3. If using target encoding, is it computed with proper cross-validation to avoid leaking the target into the feature?
4. Does your model type actually benefit from the encoding you chose, or would a simpler one work just as well?

FAQ

Is one-hot encoding always safe?
It avoids implying a false order, but it’s not free of risk. Very high cardinality columns can make the dataset unwieldy and sparse.

Can I use label encoding for tree-based models without worry?
Generally yes, more safely than with linear models, though one-hot or target encoding can still outperform it depending on the specific data.

Why is target encoding considered risky?
Because it directly incorporates target information into a feature, which makes it easy to leak test-set or future information if it isn’t computed carefully within training folds only.