Calculadora de tamanho data URI

Incorporar uma fonte, um ícone ou uma folha de estilos como data URI evita uma requisição HTTP extra, mas a codificação Base64 infla o payload em cerca de um terço e o prefixo data: ainda acrescenta mais caracteres. Devolve o comprimento exato do payload Base64, a contagem total de caracteres do data URI, a sobrecarga do payload perto de trinta e três por cento, a sobrecarga total incluindo o prefixo e uma recomendação para incorporar ou manter um link separado. Chamadas API bem-sucedidas custam US$ 0,002; entrada inválida não é cobrada.

Como o tamanho de um data URI Base64 é obtido a partir dos bytes originais

Um data URI que transporta conteúdo binário usa a forma RFC 2397: data, depois um tipo de mídia opcional, depois o token ponto-e-vírgula-base64, uma vírgula e o payload. O payload é Base64 padrão RFC 4648: cada três bytes originais viram quatro caracteres ASCII, então o comprimento codificado é exatamente quatro vezes o teto do comprimento original dividido por três. Quando o comprimento original não é múltiplo de três, sinais de igual de preenchimento completam o último quarteto para que o payload tenha sempre um múltiplo de quatro. A sobrecarga só do payload fica portanto em cerca de trinta e três por cento — exatamente um terço quando o tamanho original é múltiplo de três, e um pouco mais quando há preenchimento.

Contrato de entrada, forma da resposta e comportamento de erro

Dez mil bytes com o tipo octet-stream padrão geram um URI de 13373 caracteres e recomendação link. Envie por POST um corpo JSON com um campo obrigatório bytes: um inteiro positivo (ou string numérica) com o tamanho original do recurso antes da codificação. Os aliases size, length, n e byte_count mapeiam o mesmo parâmetro, para que scripts de empacotamento e widgets de formulário mantenham os nomes locais. O campo opcional media_type (aliases mime, type, content_type, mime_type) é o tipo MIME escrito no prefixo; se omitido, vale application/octet-stream. O campo opcional budget (aliases max, limit, max_bytes, max_size) é o maior comprimento de data URI que ainda se considera vantajoso incorporar e vale 2048 por padrão, uma regra comum em HTTP/1. Valores ausentes, vazios, não inteiros, zero ou negativos falham com invalid_input nomeando o campo; um tipo de mídia que não seja type/subtype, ou que contenha espaço ou vírgula, é rejeitado do mesmo modo. Essas falhas não são cobradas. Em sucesso o corpo ecoa bytes, media_type e budget; devolve prefix e prefix_chars; devolve base64_chars e padding_chars; devolve data_uri_chars e overhead_chars; devolve overhead_percent do URI completo frente ao arquivo original e payload_overhead_percent só do payload Base64 (a cifra de cerca de trinta e três por cento); devolve expansion_ratio como comprimento do URI sobre os bytes originais; e devolve within_budget mais recommendation igual a inline ou link. Exemplo: 1024 bytes como image/png geram um prefixo de 22 caracteres, 1368 caracteres Base64 com dois preenchimentos, um data URI de 1390 caracteres, sobrecarga de payload cerca de 33.59 por cento e recomendação inline diante do orçamento 2048. Combine os números com o próprio codificador se precisar da string; este endpoint nunca emite o payload codificado.

Quando incorporar um data URI ainda compensa a sobrecarga de trinta e três por cento

Base64 piora essa troca em cerca de um terço, e a multiplexação de HTTP/2 ou HTTP/3 deixa uma requisição à parte mais barata do que era em HTTP/1, então o tamanho de equilíbrio é menor do que muitos posts de 2012 ainda afirmam. Empacotadores que usavam um limite url-loader de oito kilobytes otimizavam sprites de HTTP/1; sobrescreva budget para 8192 se for reproduzir essa regra antiga, ou baixe o valor em sites HTTP/2. Use como portão em uma verificação de pull-request: se data_uri_chars ultrapassar o orçamento, mantenha o recurso como URL.