Response compression

Prefer zstd for JSON-RPC responses and HTTP API responses on TRON, with gzip as a compatibility fallback. Uncompressed (identity) responses remain supported for now, but are planned for removal. New integrations should support compression.

Request compressed responses

Enable your client’s zstd decoder before advertising support; some clients require an optional dependency or build feature. For clients supporting both formats, use:

Accept-Encoding: zstd, gzip;q=0.8

Higher q values take priority; equal values prefer zstd, then gzip. q=0 rejects an encoding, and explicit entries override *. See negotiation errors if all available encodings are rejected.

With curl, --compressed advertises the encodings supported by your installed build and automatically decodes the response:

curl --compressed "$RPC_URL" \
  -H "Authorization: Bearer $APP_API_KEY" \
  -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'

Set RPC_URL to your Gateway Access Point without an API Key in its path, and APP_API_KEY to your App API Key. See Authentication.

Decode the response

Follow the actual Content-Encoding, including when a proxy changes it. HTTP clients commonly decode supported responses automatically; do not decompress twice. For raw HTTP bytes, decode before parsing JSON. The decoded body is unchanged.

Read streamed responses to completion without requiring Content-Length. Individual chunks are not complete JSON documents. Negotiable responses include Vary: Accept-Encoding.

For now, absent or empty Accept-Encoding leaves responses uncompressed. Small responses also normally remain uncompressed unless identity is forbidden. Without Content-Encoding, read the body directly.

Known-empty responses bypass compression. SSE, partial responses, no-transform responses and existing encodings are passed through only when their encoding is acceptable; otherwise, see negotiation errors.

Related