Generador de claves API

Pensado para trabajar con secretos

La tarea sencilla sigue siendo rápida: elige, genera y copia. Si tu integración necesita más, dispones de codificaciones de bytes, alfabetos, etiquetas de aplicación, identificadores públicos y lotes de hasta 1.000 claves.

No necesitas cuenta ni instalación. Las explicaciones te ayudan a elegir con criterio, sin asumir que una cadena visualmente más larga siempre es más fuerte.

Formatos que encajan en tu aplicación

Base64URL evita el signo más y la barra de Base64 normal y omite el relleno. Hexadecimal resulta fácil de revisar y se acepta ampliamente, aunque ocupa más caracteres para los mismos bytes.

Base32 utiliza aquí A–Z y 2–7 sin relleno. Base64 normal conserva su relleno estándar.

Comprueba siempre lo que exige la aplicación receptora: codificar no es cifrar.

Supón que tu aplicación acepta como máximo 48 caracteres, incluido un prefijo dev_. Con 256 bits, Base64URL aporta 43 caracteres aleatorios, de modo que el resultado con el prefijo de cuatro caracteres tiene 47 en total. Hex aporta 64 caracteres aleatorios y llegaría a 68, lo que no cabe. Un sufijo consume más del mismo límite. La longitud aleatoria y longitud total que muestra la herramienta responden a preguntas distintas: la primera describe el material secreto; la segunda indica lo que debe admitir el campo receptor. RFC 4648 explica por qué las representaciones de los mismos bytes tienen longitudes diferentes. Comprueba el alfabeto del receptor además de su límite antes de elegir el formato más corto.

Alfabetos propios sin etiquetas engañosas

Puedes usar letras, dígitos, un conjunto definido de símbolos o tu propio alfabeto ASCII imprimible. Eliminamos los caracteres repetidos para que no tengan más probabilidad.

La exclusión de caracteres similares retira 0, O, 1, I, l y |. Un objetivo en bits calcula la longitud necesaria; un número exacto de caracteres permite respetar límites de campos.

Cuantas menos opciones tenga el alfabeto, más caracteres harán falta para la misma entropía teórica.

Para un alfabeto personalizado, imprimible significa aquí caracteres ASCII sin espacios: se rechazan letras acentuadas, emojis, tabuladores y espacios. Después de eliminar duplicados y, si activas esa opción, retirar caracteres similares, deben quedar al menos dos opciones distintas. Si el alfabeto deja de ser válido, cámbialo de forma deliberada en vez de esperar que la herramienta lo sustituya por otro. Los prefijos y sufijos siguen una regla diferente: cada uno puede contener hasta 32 letras ASCII, dígitos o los símbolos _ . : -. Una cadena aceptada como alfabeto no tiene por qué aceptarse como etiqueta.

El recuento exacto de caracteres se aplica a alfabetos de caracteres, no a formatos de codificación de bytes. Un límite fijo de campo no implica automáticamente una cantidad fija de aleatoriedad. Por ejemplo, 32 caracteres hexadecimales elegidos uniformemente tienen 128 bits teóricos, mientras que 32 elecciones de un alfabeto de 64 caracteres distintos tienen 192. Si el campo es demasiado corto para el tamaño que exige la aplicación, no trunques un valor ya generado ni cuentes su etiqueta como caracteres aleatorios. Elige una representación compatible y revisa el cálculo resultante antes de generar; si no cabe ninguna combinación permitida, hay que aclarar el requisito de la aplicación.

Puntos de partida, no credenciales de proveedores

Token de API empieza con Base64URL de 256 bits. Secreto de webhook usa hexadecimal de 256 bits para tu propio sistema de verificación con secreto compartido.

Secreto de aplicación utiliza Base64URL de 512 bits; Lote de desarrollo prepara diez tokens de 256 bits. Son atajos de configuración, no estándares universales ni claves emitidas por proveedores.

Los prefijos y sufijos identifican aplicaciones o entornos. Añadir live_ no activa la clave ni concede permisos.

De una clave a una exportación organizada

Copia secretos individuales o el lote completo. Los pares opcionales añaden un identificador público aleatorio de 96 bits para localizar el registro; conserva el secreto privado y no autentiques con el ID.

JSON mantiene los valores exactos. TXT admite líneas, comas o espacios.

CSV escapa celdas y neutraliza comienzos de fórmula, a veces añadiendo un apóstrofo. .env valida nombres y rechaza comillas incompatibles. Está pensado para Node dotenv, no para ejecutarlo como script de consola.

Las descargas contienen secretos en texto plano, no copias cifradas.

Ocultar resultados ayuda cuando la pantalla está a la vista de otras personas, pero los 24 puntos de máscara son una convención visual, no la longitud del secreto. Al copiar y exportar se siguen usando los valores reales. Cambiar los ajustes de generación borra el lote mostrado, incluido un cambio de formato: prepara una generación nueva en lugar de convertir el secreto anterior a otra codificación. Transfiere de forma segura un lote que necesites antes de cambiar esos ajustes. Dentro del diálogo de exportación, cambiar el formato de archivo o el separador TXT solo reformatea ese mismo lote.

Solo se muestran 20 resultados por página, pero Copiar todo y la exportación usan el lote completo. Con pares de ID activados, el botón Copiar individual copia solo el secreto. JSON sin pares es un array de cadenas; con pares es un array de objetos con los campos key_id y api_key. Comprueba que tu código de importación espera esa estructura en vez de tratar el identificador público como un segundo secreto o asumir que la primera página visible es toda la descarga. Mantén asociado el ID elegido con su secreto al registrar credenciales.

Elige JSON cuando una máquina deba recibir los caracteres exactos del secreto. CSV está preparado para verlo en hojas de cálculo: un valor que empieza como fórmula, por ejemplo -example, puede recibir un apóstrofo inicial, de modo que un lector CSV genérico quizá lea un valor literal distinto. El ejemplo es inventado, no una clave utilizable. No elimines apóstrofos de todas las claves importadas; un apóstrofo también puede ser una salida legítima del alfabeto. La guía de OWASP sobre inyección CSV explica tanto la interpretación de fórmulas como los límites del escape para hojas de cálculo. Volver a guardar un CSV en una hoja de cálculo no es una garantía universal de seguridad y añade una manipulación innecesaria para un secreto de producción.

Para .env, un nombre como APP_TOKEN es válido; 1TOKEN o APP-TOKEN no lo son. La herramienta limita el nombre a 64 caracteres y rechaza valores que contengan comillas dobles o barras inversas en lugar de adivinar cómo los interpretará otro cargador. Node.js documenta su propia sintaxis dotenv; comprueba por separado la compatibilidad con los otros programas que vayan a leer el archivo. Si la exportación rechaza un valor de alfabeto personalizado, usa JSON o una transferencia controlada adecuada para esa aplicación. Cambiar el nombre de un archivo descargado no elimina los caracteres incompatibles, y un archivo .env con secretos sigue necesitando almacenamiento protegido.

Cómo calculamos bits, bytes y caracteres

Para formatos de bytes obtenemos ceil(bits objetivo / 8) bytes aleatorios y mostramos bytes × 8 bits nominales. Con N caracteres independientes y uniformes elegidos entre A caracteres distintos, la entropía teórica es N × log₂(A).

Un objetivo requiere ceil(bits objetivo / log₂(A)) caracteres. Por ejemplo, 256 bits solo con números necesitan 78 dígitos, no 32.

Prefijos, sufijos e identificadores públicos separados no cuentan como entropía del secreto. Son cálculos del diseño de generación, no una medición ni certificación de la fuente aleatoria del navegador.

Nuestra metodología de generación

Usamos crypto.getRandomValues y exigimos un contexto seguro. Nunca recurrimos a Math.random, marcas de tiempo, actividad del teclado o semillas predecibles.

Las codificaciones de bytes son representaciones sin pérdida. Para alfabetos aplicamos muestreo por rechazo: descartamos el resto desigual antes de asignar bytes a caracteres.

Esto evita el sesgo de aplicar módulo a todos los bytes cuando el tamaño del alfabeto no divide 256. Cada lote se comprueba para detectar secretos e identificadores repetidos.

Los reintentos están limitados y un fallo no entrega un resultado incompleto.

Qué permanece en tu navegador

La generación y preparación de exportaciones son locales. ClockTools no envía las claves a sus servidores ni las coloca en URLs, analítica o almacenamiento persistente.

Incluso al llegar desde otra herramienta, esta página abre un documento nuevo sin nuestros cargadores de analítica ni grabación de sesiones. Los ajustes guardados y compartidos excluyen campos libres y claves.

El proveedor de alojamiento sigue recibiendo las peticiones normales de página. Copiar envía el valor al portapapeles; descargar crea un archivo en texto plano.

Extensiones, portapapeles sincronizados, malware o alguien mirando la pantalla siguen siendo riesgos. Borrar elimina los resultados de la interfaz, sin garantizar el borrado seguro de memoria ni eliminar copias externas.

Cómo usar una clave de forma segura

Una cadena aleatoria se convierte en credencial API cuando tu aplicación la registra y verifica. Configura allí privilegios mínimos, HTTPS, revocación, caducidad y rotación.

No incluyas secretos del servidor en código frontend ni repositorios. Para producción, utiliza una gestión de secretos adecuada.

En entornos sensibles conviene generar dentro de tu propia infraestructura de confianza. Los ejemplos de Node.js, Python y OpenSSL crean secretos nuevos localmente, sin copiar valores de una web.

Ningún sitio garantiza que el navegador o dispositivo esté libre de compromisos.

Qué comprobamos y qué no demuestran las pruebas

Las pruebas de regresión cubren longitudes, vectores de codificación conocidos, alfabetos, muestreo por rechazo, entropía, afijos, duplicados, exportaciones y serialización segura de ajustes. Estas pruebas automatizadas no demuestran la fiabilidad en todos los navegadores y dispositivos ni verifican el comportamiento del portapapeles del sistema, el guardado de archivos o la analítica del sitio publicado.

La ausencia de duplicados o una distribución visualmente uniforme no demuestra aleatoriedad criptográfica. La herramienta no está certificada de forma independiente y nuestras pruebas no son una auditoría de toda tu aplicación.

Informa de errores sin revelar secretos

Indica formato, modo de longitud, bits o caracteres, cantidad, navegador y pasos para reproducir el problema. Usa ejemplos inventados en lugar de claves activas, secretos de webhook o datos de clientes.

Aplicamos nuestra política de correcciones. Ante un defecto importante confirmado, debemos explicar el comportamiento afectado, añadir una prueba de regresión e indicar si es necesario regenerar claves anteriores.

Cambiar esta página no revoca claves registradas en otros sistemas; debes sustituirlas o revocarlas allí.

Generar en tu propio equipo

Los ejemplos crean un secreto nuevo con el formato y los afijos elegidos. Nunca incluyen la clave mostrada ni crean cuentas, permisos o reglas de caducidad. No incluyen identificadores públicos ni generación por lotes.

import { randomBytes } from 'node:crypto';
const key = "" + randomBytes(32).toString('base64url') + "";

Preguntas frecuentes

Fuentes y herramientas relacionadas

Metodología y limitaciones: Web Crypto · RFC 4648

Generador de GUID · Metodología y limitaciones · Política de correcciones