为何JWT的Payload采用Base64编码而非DES等对称加密算法？

First off, great question—this gets right to the heart of JWT's core design goals, which are often misunderstood. Let's unpack this:

• JWT isn't meant to hide payload data by default
  The primary purpose of JWT is to provide verifiable integrity (proving the payload hasn't been tampered with) and identity assertion, not to keep the payload secret. Think about common payloads: user IDs, role names, expiration timestamps—these are often non-sensitive data that don't need encryption. Base64 is just an encoding scheme (not encryption!) to convert binary/non-ASCII data into a URL-safe string format for easy transmission across HTTP headers or URLs.

• Symmetric encryption like DES introduces unnecessary complexity and risks
  If you encrypted the payload with DES, every service that needs to parse the JWT would need access to the same secret key. In distributed systems (microservices, cloud environments), managing this shared key is a nightmare:

  • Key leaks become a critical risk—if one service is compromised, all services using the key are vulnerable.
  • Rotating the key requires coordinating updates across every service that handles the JWT, which is error-prone and disruptive.

• JWT already has a standardized solution for encrypted payloads: JWE
  If you do need to keep your payload confidential, you don't have to reinvent the wheel with DES. JWT has an encrypted variant called JSON Web Encryption (JWE). JWE supports multiple modern encryption algorithms (including more secure symmetric ciphers like AES, which replaces outdated DES) and asymmetric options. It handles key management and encryption properly, following industry standards so you don't have to build custom logic.

• Performance and compatibility tradeoffs
  Base64 encoding/decoding is blazingly fast with almost no computational overhead—perfect for high-traffic applications. Encryption and decryption (even with DES) add measurable latency, which can add up in busy systems. Plus, every mainstream JWT library natively supports Base64 payloads; rolling your own DES-encrypted payload would mean writing custom parsing logic, breaking compatibility with existing tooling.

• Transparency is often a requirement
  In many cases, you want intermediate systems or even client-side code to read parts of the payload. For example, a frontend app might need to grab the user's display name from the JWT to show in the UI. If the payload was encrypted, that wouldn't be possible without decrypting it first, which defeats the point of having that data easily accessible.

内容的提问来源于stack exchange，提问作者zhangtaichao