-
Notifications
You must be signed in to change notification settings - Fork 4k
Description
Checklist
- I have searched the existing issues for similar feature requests.
- I added a descriptive title and summary to this issue.
Summary
Add a max_size parameter to st.file_uploader to allow developers to restrict the maximum file size before the file is uploaded. This would provide immediate feedback to the user and prevent large files from being uploaded unnecessarily.
Why?
Currently, Streamlit only allows file size limitation through:
- Post-upload checks (file.size).
- Global configuration via maxUploadSize in config.toml.
This creates a few problems:
- Bandwidth waste: Large files are uploaded even if they will later be rejected.
- Poor UX: Users receive feedback only after the upload has completed.
- Lack of granularity: You can’t set different file size limits for different uploaders in the same app.
- No UI indication: The upload widget does not show any size limitation unless the global config limit is exceeded.
How?
Add an optional max_size parameter (in bytes, KB, or MB) to st.file_uploader. For example:
st.file_uploader(
"Upload your data",
max_size=5 * 1024 * 1024
) # 5MB
Expected behavior:
- Files larger than the specified limit are not accepted.
- A clear, user-friendly error message is shown before the upload begins (e.g., "File exceeds 5MB limit").
- Consistent feedback across the UI.
This should work independently of the global maxUploadSize setting and would allow per-upload granularity.
Additional Context
Currently, developers are forced to do this after the file has already been uploaded:
uploaded_file = st.file_uploader("Upload a file")
if uploaded_file is not None:
if uploaded_file.size > 5 * 1024 * 1024:
st.error("File too large! Maximum allowed is 5MB.")
This defeats the purpose in many use cases, especially when working with limited bandwidth, slow connections, or when handling large files that could affect performance or cost.
This feature is common in many web frameworks and frontend components, and would be a great improvement to Streamlit’s already excellent developer experience.