### What problem are you trying to solve?my wallets and my redraw

[Shikho18]

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:

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:

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:

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

Example usage:

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)?

Originally posted by @hemanth in whatwg/fetch#1800