## TL;DR

Each worker secret value has a per-value size cap of a few kilobytes, and your value is over it. This usually happens when pasting a whole JSON service-account key or a certificate chain as one secret. Either split the value across several numbered secrets and reassemble it in code, or store the blob in KV or R2 and keep only a pointer in the secret.

```text
Error: secret value too long
```

## Steps

1. Measure how big the value actually is. Save it to a temp file and count the bytes:
```sh
wc -c /tmp/my-secret-value.txt
```
Expected: a byte count. Anything in the multi-kilobyte range is over the per-value cap for a single secret.

2. Decide the shape. If the value is a JSON key or cert that is only slightly over, split it into chunks (for example MY_KEY_PART_1 and MY_KEY_PART_2) and join them at runtime. If it is a large blob, upload it to KV or R2 instead and store only the object key as the secret.
Expected: each individual secret value is well under the cap.

3. Set the secrets one at a time with `wrangler secret put`, pasting each chunk when prompted. Do not pipe with plain echo, which appends a trailing newline and changes the value; use printf if piping from a file.
Expected: wrangler reports each secret was created.

4. Verify the names landed (values are never shown back):
```sh
wrangler secret list
```
Expected: your secret names appear in the list.

5. In the worker, read the parts from the environment and reassemble before use, or fetch the blob from KV or R2 using the pointer secret. Deploy and exercise the code path that consumes it.
Expected: the worker reads the full value correctly at runtime.

## Use this when
- `wrangler secret put` fails with "secret value too long"
- Storing a JSON service-account key, certificate chain, or long private key as one secret
- A secret that used to fit grew past the cap after a key rotation

## Not for this skill when
- The secret name is invalid (different error about the name format)
- The worker cannot read a secret that was set fine (binding or env mismatch)
- You need the value back after setting it; secrets are write-only by design

## Variant phrasings
- wrangler secret put value exceeds max length
- cloudflare worker secret too large to store
- secret value exceeds the allowed size wrangler

## Why it happens

Worker secrets are encrypted environment variables, and the platform caps each value at a few kilobytes to keep deploys and the runtime config small. Service-account JSON and cert chains routinely exceed that, so they need chunking or a storage binding instead of one giant secret.

## Edge cases
- Setting a secret triggers a deploy of the worker immediately; plan rotations accordingly.
- `wrangler secret list` shows names only; there is no read-back, so keep the source of truth somewhere safe.
- Chunked secrets must all be present or the reassembly silently produces a corrupt value; validate the joined length at startup.
- Binary data should be base64-encoded before storing, which grows it by about a third; budget for that.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_cr4MO4Uz_bULUl-d66iXKA