Forum Discussion
Power BI automatically normalizing text casing during data load
Hi KumbharM,
Thanks for reaching out to the Microsoft Fabric Community forum.Yes, the behavior described is documented for Power BI.
The Power BI engine that stores and queries data is case insensitive, so it treats text values that differ only by capitalization as the same value. In contrast, Power Query is case sensitive, so it can display the casing as stored in the source before the data is loaded into the Power BI model.Microsoft also explains that, when data is loaded, the Power BI engine evaluates rows from top to bottom and maintains a dictionary of unique text values. When it encounters values that differ only by case, they are treated as the same value and the existing variation is referenced. Therefore, the capitalization displayed in the model can correspond to the first variation encountered during loading.
This explains the behavior in the example where PunE, Pune, pune, and PUNE are loaded and subsequently displayed using the casing of the first occurrence.
For a connector scenario, once the values are loaded into the Power BI engine, case-only variations are treated as the same value. The Microsoft documentation specifically recommends, for DirectQuery with a case-sensitive data source, normalizing casing in the source query or in Power Query Editor.
For more details, please refer to the below Official Microsoft Documentation:
Data types in Power BI - Power BI | Microsoft Learn
DirectQuery in Power BI: When to Use, Limitations, Alternatives - Power BI | Microsoft LearnI hope this helps. Please feel free to reach out if you have any further questions.
Thank you.
Community ChampionHi KumbharM,
v-abhinavmu's explanation is correct. I would add one important qualification around the workaround.
Microsoft's current Power BI data type documentation explicitly states that Power Query is case-sensitive, while the Power BI engine that stores and queries the data is case-insensitive.
That means values such as:
PunE
Pune
pune
PUNEcan remain distinct in Power Query, but once loaded into the semantic model the engine can treat them as the same text value and retain one casing as the canonical representation.
So from a connector perspective, I would not expect there to be a flag that disables this behaviour after the data reaches the Power BI engine.
I would also be careful with DirectQuery as a workaround.
Microsoft specifically warns that when DirectQuery is used against a case-sensitive source, values that differ only by case can produce undefined results because the source and Power BI disagree about whether those values are distinct.
Microsoft's documented recommendation in that situation is to normalize the casing in the source query or in Power Query before the values reach the model.
So if City is logically case-insensitive, I would standardize it upstream, for example to one agreed representation, rather than rely on whichever casing is encountered first during model loading.
If the different casing is actually meaningful business data and PunE, Pune and PUNE must remain separate values, then I would treat that as a modelling requirement rather than only a connector-formatting issue. The standard Power BI semantic model behaviour does not provide a reliable way to preserve case-only distinctions in one text column.
I would also avoid adding invisible or extra characters simply to force the values to remain distinct unless there is a very specific reason, because that changes the actual values and can affect relationships, filtering and comparisons.
So for a custom connector, the safest design is normally:
- preserve the source values in Power Query
- decide explicitly whether casing has business meaning
- if casing does not matter, normalize it before model load
- if casing does matter, redesign the key/model so uniqueness does not depend only on letter casing
Microsoft also covers the same DirectQuery caution in the DirectQuery guidance.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.