`bind="query-params"` doesn't add the the value to query string if the default value is chosen

[zcabaal]

Checklist

• I have searched the existing issues for similar issues.
• I added a very descriptive title to this issue.
• I have provided sufficient information below to help reproduce this issue.

Summary

Binding query params doesn't add the value to the url query string if the default is chosen

For example, in

import streamlit as st


st.selectbox(
    "Choose an option:",
    ["Option1", "Option2", "Option3"],
    index=0,
    bind="query-params",
    key="key1",
)


st.multiselect(
    "Choose an option or more:",
    ["Option1", "Option2", "Option3"],
    default=["Option1"],
    bind="query-params",
    key="key2",
)

In both widget, selecting Option1 will remove the value from the query string.
If I select Option2, it gets added to the url query string, but if I select Option1 again it get removed

I would like the default to be added in the url (or have a parameter that enables this behaviour). In dymanic apps where options and default values can change, being able to share a url containing all values (including those set to the default value), will ensure that the shared url always contains the same values even if the defaults change

Reproducible Code Example

Steps To Reproduce

No response

Expected Behavior

No response

Current Behavior

No response

Is this a regression?

• Yes, this used to work in a previous version.

Debug info

Streamlit version: 1.59.2
Python version: 3.13.13
Operating System: Ubuntu 24.04
Browser: Chrome

Additional Information

No response

[github-actions]

If this issue affects you, please react with a 👍 (thumbs up emoji) to the initial post.

Your feedback helps us prioritize which bugs to investigate and address first.

[sfc-gh-nbellante]

Thanks for the detailed report, @zcabaal — I can reproduce this on 1.59.2 and it's still the behavior on develop.

This is actually working as designed rather than a bug in the wiring: bind="query-params" deliberately keeps URLs clean by only serializing non-default values. When a bound widget's value equals its default (index=0 for selectbox, default=["Option1"] for multiselect), the param is intentionally removed from the URL — both on first render and when you re-select the default. This is enforced consistently on the frontend and backend.

That said, your use case is a good one that the current design doesn't cover: in dynamic apps where the options or defaults can change, a shared URL that omitted the default won't reproduce the same selection later. Forcing the value into the URL regardless of the default is a reasonable capability we don't offer today — so I'm reframing this as an enhancement (an opt-in to always serialize bound values), which the team can weigh in on.

In the meantime, you can get the "always include the value" behavior by syncing manually instead of using bind:

options = ["Option1", "Option2", "Option3"]
opt = st.selectbox(
    "Choose an option:",
    options,
    index=options.index(st.query_params.get("key1", "Option1")),
    key="key1",
)
st.query_params["key1"] = opt  # written even when it's the default

This writes the value on every run regardless of whether it matches the default, so shared URLs stay stable even if the defaults change.

[github-actions]

To help Streamlit prioritize this feature, react with a 👍 (thumbs up emoji) to the initial post.

Your vote helps us identify which enhancements matter most to our users.

[sahilmathur254]

Hi, I’d be interested in implementing a backwards-compatible opt-in rather than changing the default behaviour. Would you prefer this to be expressed on the binding itself? For example, an option meaning “always serialise” or as a separate widget argument?
For a first PR, I would scope it to the selectbox and multiselect, cover both initial render and re-selecting the default, and leave other bound widgets for follow-up once the API shape is validated.

[zcabaal]

Hi, I’d be interested in implementing a backwards-compatible opt-in rather than changing the default behaviour. Would you prefer this to be expressed on the binding itself? For example, an option meaning “always serialise” or as a separate widget argument? For a first PR, I would scope it to the selectbox and multiselect, cover both initial render and re-selecting the default, and leave other bound widgets for follow-up once the API shape is validated.

Both options (another bind= option or a seperate widget argument) are fine for me. I don't have a particular preference. Thank you

[sahilmathur254]

Thanks! I’ll wait for someone from the Streamlit team on the preferred API shape before implementing.
Once that is confirmed, I’ll keep the initial PR focused on selectbox and multiselect, covering initial render and re-selecting the default value.