[whatwg/fetch] Proposal: response.base64() (Issue #1800)

### What problem are you trying to solve?

## Problem Statement

Currently, when working with the Fetch API, converting response data to base64 encoding requires multiple steps and introduces complexity, especially when handling binary data. Developers often need to:

1. Read the response as a blob or array buffer
2. Convert it to base64 using additional utilities
3. Handle potential encoding issues

This process is error-prone and requires additional code that could be standardized.

### What solutions exist today?

## Existing Solutions

Currently, developers typically handle this in one of these ways:

1. Using FileReader:
```javascript
const response = await fetch(url);
const blob = await response.blob();
const reader = new FileReader();
reader.readAsDataURL(blob);
await new Promise(resolve => reader.onload = resolve);
const base64 = reader.result.split(',')[1];
```

2. Using array buffers and manual conversion:
```javascript
const response = await fetch(url);
const buffer = await response.arrayBuffer();
const bytes = new Uint8Array(buffer);
const binary = bytes.reduce((data, byte) => data + String.fromCharCode(byte), '');
const base64 = btoa(binary);
```

Both approaches have drawbacks:
- Verbose and complex code
- Performance overhead from multiple conversions
- Inconsistent handling across different types of content
- Memory inefficient due to multiple data copies


### How would you solve it?

## Proposed Solution

Add a new method `base64()` to the Response prototype:

```javascript
interface Response {
  base64(): Promise<string>;
}
```

Example usage:
```javascript
const response = await fetch('https://example.com/image.png');
const base64Data = await response.base64();
```

### Implementation Details

The method would:
1. Efficiently read the response body
2. Convert it directly to base64 encoding
3. Return a Promise that resolves with the base64 string

### Benefits

1. **Simplicity**: Single method call instead of complex conversion chains
2. **Performance**: Native implementation can optimize the conversion process
3. **Memory efficiency**: Avoid unnecessary intermediate copies
4. **Standardization**: Consistent behavior across browsers
5. **Error handling**: Built-in handling of encoding edge cases

### Compatibility

The method name `base64()` is not currently used in the Response prototype, making it safe to add. The method would return a Promise to maintain consistency with other Response body reading methods.

## Additional Considerations

### Security

- The method should respect same-origin policies
- Large responses should be handled efficiently to prevent memory issues
- Consider adding optional parameters for handling different encodings

### Edge Cases

- Handle empty responses
- Consider adding options for URL-safe base64 encoding
- Define behavior for streaming responses

### Performance Impact

- Native implementation can optimize the conversion process
- Consider chunked processing for large responses
- Potential for WebAssembly acceleration


### Anything else?

## Open Questions

1. Should there be a size limit for automatic base64 conversion?
2. Should streaming be supported for large responses?
3. Should there be options for different base64 variants (standard, URL-safe)?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1800
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1800@github.com>