Introduction

Django templates intentionally keep logic limited, which is why dictionary lookup with a variable key is less direct than it would be in plain Python. If you need my_dict[some_variable] style behavior in a template, the cleanest answer is usually either to prepare the value in the view or to add a tiny custom template filter.

Understand What the Template Engine Does by Default

Django templates support dotted lookup such as user.name or mapping.key, but that is not the same as full Python indexing with an arbitrary variable key.

For example, this works when the key is literally status:

{{ mapping.status }}

But this does not mean Django will automatically interpret another variable as a dynamic key in every case. The template language is intentionally simpler than Python.

Prefer Preparing the Value in the View

If the template needs only one derived lookup, compute it before rendering. This keeps the template simple and avoids custom tags for trivial cases.

1from django.shortcuts import render
2
3
4def dashboard(request):
5    stats = {"apples": 4, "oranges": 9}
6    selected_key = "apples"
7
8    context = {
9        "selected_key": selected_key,
10        "selected_value": stats.get(selected_key),
11    }
12    return render(request, "dashboard.html", context)

Then the template stays straightforward:

<p>{{ selected_key }}: {{ selected_value }}</p>

This is often the best option when the lookup is part of view logic rather than presentation logic.

Add a Custom Filter for Reusable Dynamic Lookup

If variable-based dictionary access appears repeatedly across templates, write a small custom filter.

Create templatetags/dict_extras.py:

1from django import template
2
3register = template.Library()
4
5
6@register.filter
7def get_item(mapping, key):
8    if mapping is None:
9        return None
10    return mapping.get(key)

Then load and use it in the template:

{% load dict_extras %}

<p>{{ stats|get_item:selected_key }}</p>

This is the standard reusable answer because it keeps the logic small and explicit without trying to turn Django templates into unrestricted Python.

Keep Missing-Key Behavior Deliberate

Decide what should happen when the key is absent. Using .get(key) usually returns None, which renders as an empty string in many template contexts. That may be fine, or it may hide a bug.

If missing keys should be visible, make the filter more explicit:

1@register.filter
2def get_item_or_default(mapping, key):
3    if mapping is None:
4        return "missing"
5    return mapping.get(key, "missing")

That choice depends on whether the lookup is optional presentation data or required business data.

Avoid Forcing Complex Logic into Templates

Once a template starts doing several dependent lookups, conditional fallbacks, or nested transformations, it is usually a sign that the data shape should be prepared earlier. Django templates are designed to stay readable for designers and reviewers. Heavy logic belongs in:

• the view
• the serializer
• the model or service layer
• a focused custom template tag when presentation reuse really needs it

The goal is not to show that a lookup is technically possible in the template. The goal is to keep the rendering layer easy to understand.

Common Pitfalls

• Expecting Django templates to support arbitrary Python dictionary indexing syntax directly.
• Writing complex lookup logic in templates when the view could prepare the exact value once.
• Creating a custom filter but forgetting to load the templatetags module in the template.
• Returning None for missing keys without deciding whether silent failure is acceptable.
• Using template filters as a substitute for proper data shaping in the view layer.

Summary

• Django templates are intentionally limited, so dynamic dictionary lookup is not as free-form as in Python code.
• The simplest solution is often to compute the looked-up value in the view.
• For reusable dynamic access, create a small custom filter such as get_item.
• Decide explicitly how missing keys should behave.
• Keep templates focused on presentation rather than complex data manipulation.