Base64 및 URL 인코더
기기에서 실행되며 아무것도 전송되지 않습니다.모든 작업은 사용자의 기기에서만 이루어집니다. 입력하거나 업로드한 내용은 어디로도 전송되지 않습니다.
텍스트
결과
결과가 여기에 표시됩니다
Base64 및 URL로 인코딩된 문자열을 브라우저에서만 인코딩하거나 디코딩하고, 파일을 Base64로 변환하세요.
Base64는 64개의 인쇄 가능한 문자를 사용해 임의의 이진 데이터를 순수한 ASCII 텍스트로 변환합니다. 그래서 이미지를 CSS나 HTML에 직접 포함시키거나, 파일을 이메일에 첨부하거나, JWT 안에 토큰을 인코딩하는 등 이진 데이터가 텍스트 전용 채널을 통과해야 하는 모든 곳에서 사용됩니다. URL 인코딩(퍼센트 인코딩)은 이와는 별개의 다른 방식으로, 공백이나 앰퍼샌드처럼 URL이 그대로 포함할 수 없는 문자를 이스케이프하여 쿼리 문자열에 배치되어도 손상되지 않도록 합니다. 이 도구는 두 방식 모두에 대해 텍스트나 파일을 양방향으로 변환하며, 모두 브라우저에서만 이루어집니다 - 어디로도 업로드되지 않습니다.
자주 묻는 질문
Base64는 암호화인가요?
아니요. Base64는 암호화가 아니라 인코딩입니다 - 이 도구를 포함해 누구나 키나 비밀번호 없이 즉시 디코딩할 수 있습니다. 텍스트가 아닌 바이너리를 예상하는 시스템을 안전하게 통과할 수 있도록 데이터의 표현 방식만 바꿀 뿐입니다. 민감한 정보를 숨기는 용도로는 절대 사용하지 마세요.
Base64로 인코딩된 텍스트가 = 기호로 끝나는 이유는 무엇인가요?
Base64는 3바이트 단위로 처리되며, 각 단위는 4개의 출력 문자로 변환됩니다. 입력이 3바이트의 배수가 아니면 = 문자가 마지막 단위를 4자로 채웁니다. URL 안전 형식은 디코더가 보통 문자열 길이로부터 이를 추론할 수 있기 때문에 일반적으로 이 패딩을 생략합니다.
표준 알파벳과 URL 안전 알파벳의 차이는 무엇인가요?
표준 Base64는 64개 문자 중 두 개로 +와 /를 사용하지만, 둘 다 URL 안에서 특별한 의미를 가지므로(각각 공백과 경로 구분자) 표준 Base64 문자열을 URL이나 파일 이름에 직접 넣으면 깨질 수 있습니다. URL 안전 형식은 이 두 문자를 -와 _로 대체하며, 이것이 JWT 및 유사한 토큰에서 사용되는 형식인 이유입니다.
디코딩 시 텍스트 대신 바이너리 데이터가 표시되는 경우는 왜 그런가요?
Base64는 텍스트뿐만 아니라 이미지, 글꼴 파일, 실행 파일 등 문자 그대로 어떤 바이트든 인코딩할 수 있습니다. 디코딩된 바이트가 유효한 UTF-8 텍스트를 이루지 않으면 이 도구는 이를 읽을 수 있는 문자열로 표시할 수 없지만, 다운로드를 통해 파일로 저장하여 원본 바이너리 콘텐츠를 복구할 수 있습니다.
Base64로 인코딩된 결과물이 원본보다 약 3분의 1 더 커지는 이유는 무엇인가요?
Base64는 입력 3바이트마다 4개의 출력 문자를 대응시키므로, 텍스트 일부를 인코딩하든 파일 전체를 인코딩하든 인코딩된 결과는 항상 원본보다 약 4/3배(약 33%) 더 커집니다. 이러한 오버헤드는 임의의 이진 데이터를 단 64개의 인쇄 가능한 문자만으로 표현하기 위한 대가이며, 정상적인 현상이므로 문제가 생긴 것이 아닙니다.
URL 안전 Base64 문자열을 디코딩하기 전에 "URL 안전 알파벳"을 켜야 하나요?
아니요 - 문자열이 표준 알파벳을 사용하든 URL 안전 알파벳을 사용하든 디코딩은 항상 작동합니다. 내부적으로 이 도구는 -와 _를 자동으로 +와 /로 되돌리고 부족한 = 패딩도 스스로 채워주므로, 두 형식 중 어느 것이든 디코드 모드에 바로 붙여넣을 수 있습니다. 이 체크박스는 출력이 어떤 알파벳을 사용할지 결정하므로 인코딩할 때만 의미가 있습니다.
개발자를 위한 안내: URL에 `q` 매개변수를 붙여 이 페이지를 열면 - 예: gizke.com/base64?q=hello world - 해당 값이 자동으로 미리 입력됩니다. 대부분의 방문자에게는 필요하지 않으며, 바로 사용할 수 있는 예시로 직접 링크하기 위한 기능입니다.