supabase
content type not taken into account in storage
Describe the bug I'm simply uploading a .html file on a storage bucket. When fetching the file from a browser thanks to the direct url, the content type is set to plain/text.
To Reproduce I have tried by two ways.
Simply saving any html page from the web (I used this one : https://supabase.com/docs/reference/cli/supabase-storage) and uploading it on a supabase bucket from the console. Then getting the link and trying the fetch it with the browser.
Another way is to use the AWS CLI :
AWS_PROFILE="supabase" aws s3 cp dist/index.html s3://bucketname/index.html --content-type "text/html" --debug
In the debug logs, I can clearly see I'm uploading with text/html type, but the answer already turned it into plain/text.
`2025-11-02 18:05:46,484 - ThreadPoolExecutor-0_0 - botocore.auth - DEBUG - Calculating signature using v4 auth. 2025-11-02 18:05:46,484 - ThreadPoolExecutor-0_0 - botocore.auth - DEBUG - CanonicalRequest: PUT /storage/v1/s3/bucketname/index.html
content-encoding:aws-chunked content-type:text/html host:projectid.storage.supabase.co x-amz-content-sha256:STREAMING-UNSIGNED-PAYLOAD-TRAILER x-amz-date:20251102T170546Z x-amz-decoded-content-length:4025 x-amz-sdk-checksum-algorithm:CRC64NVME x-amz-trailer:x-amz-checksum-crc64nvme
content-encoding;content-type;host;x-amz-content-sha256;x-amz-date;x-amz-decoded-content-length;x-amz-sdk-checksum-algorithm;x-amz-trailer STREAMING-UNSIGNED-PAYLOAD-TRAILER 2025-11-02 18:05:46,484 - ThreadPoolExecutor-0_0 - botocore.auth - DEBUG - StringToSign: AWS4-HMAC-SHA256 20251102T170546Z 20251102/eu-west-3/s3/aws4_request 69dc5715fd941a5ea65ea3c43de1c5df4c49fda152d83d73a9dbd5ec74b4c4af 2025-11-02 18:05:46,484 - ThreadPoolExecutor-0_0 - botocore.endpoint - DEBUG - Sending http request: <AWSPreparedRequest stream_output=False, method=PUT, url=https://projectID.storage.supabase.co/storage/v1/s3/bucketname/index.html, headers={'Content-Type': b'text/html', 'x-amz-sdk-checksum-algorithm': b'CRC64NVME', 'User-Agent': b'aws-cli/2.28.18 md/awscrt#0.27.5 ua/2.1 os/macos#24.6.0 md/arch#arm64 lang/python#3.13.7 md/pyimpl#CPython m/Z,E,G,W,N,b cfg/retry-mode#standard md/installer#source sid/effe64ac3fb0 md/prompt#off md/command#s3.cp', 'Expect': b'100-continue', 'Transfer-Encoding': b'chunked', 'Content-Encoding': b'aws-chunked', 'X-Amz-Trailer': b'x-amz-checksum-crc64nvme', 'X-Amz-Decoded-Content-Length': b'4025', 'X-Amz-Date': b'20251102T170546Z', 'X-Amz-Content-SHA256': b'STREAMING-UNSIGNED-PAYLOAD-TRAILER', ........
2025-11-02 18:05:46,727 - ThreadPoolExecutor-0_0 - botocore.parsers - DEBUG - Response headers: {'Date': 'Sun, 02 Nov 2025 17:05:46 GMT', 'Content-Type': 'text/plain', 'Content-Length': '0', 'Connection': 'keep-alive', 'Server': 'cloudflare', 'CF-Ray': '998537fa7a53d808-CDG', 'CF-Cache-Status': 'DYNAMIC', 'Access-Control-Allow-Origin': '*', 'ETag': '"12916a47d7d1609f9d23dc47bfb94935"', 'Strict-Transport-Security': 'max-age=31536000; includeSubDomains; preload', 'Content-Security-Policy': "default-src 'none'; sandbox", 'sb-gateway-mode': 'direct', 'sb-gateway-version': '1', 'sb-project-ref': 'onhyimzjjkokqqgxbmxw', 'sb-request-id': ...
Expected behavior That the content type is well taken into account when set, or automatically well detected from the extension of the file, and not the 512 first bytes of the file as I read somewhere on the deep mysterious web...
Additional context
- Browser Firefox
- aws-cli/2.28.18 Python/3.13.7 Darwin/24.6.0 source/arm64
Thank you very much for your work on this impressive project. Regards,
I am experiencing the same issue. Bucket is incapable of serving content-type HTML, and always converts to plain text.
Saw a previous discussion flagging this line of code in the supabase repo related to this: https://github.com/supabase/storage/blob/430760dcba96df15fc2342c12e0b21460fbfec67/src/storage/renderer/renderer.ts#L151
the 512 first bytes of the file as I read somewhere on the deep mysterious web...
I read that here: https://github.com/supabase/cli/issues/1895#issuecomment-1920503284
