JSON 정렬, Base64·URL 인코드/디코드, 정규식 테스트, JWT 디코드, Cron 해석, 텍스트 비교까지 자주 쓰는 변환기를 브라우저에서 바로 사용할 수 있어요.
모든 변환·검사는 브라우저 안에서 처리돼 입력한 데이터가 서버로 전송되지 않아요. 토큰이나 개인정보가 든 텍스트도 안심하고 다룰 수 있어요.
들여쓰기는 부수효과예요. 실제 쓸모는 문법 오류 위치를 짚어 주는 것이에요. API 응답이 «잘못된 JSON» 이라고만 뜰 때, 몇 번째 문자에서 깨졌는지 알면 원인이 바로 보여요.
흔한 원인 셋 — 후행 쉼표(마지막 항목 뒤 `,`), 작은따옴표(JSON 은 큰따옴표만), 주석(JSON 에는 주석이 없어요).
키를 알파벳순으로 정렬하면 두 응답을 비교할 때 차이만 남아요. 순서가 다른 같은 데이터를 diff 로 비교하면 전부 다르다고 나오거든요.
Base64 는 바이너리를 텍스트로 옮기는 인코딩이에요. 이메일·JSON 처럼 텍스트만 다루는 통로에 이미지나 바이트를 실어 보내려고 만들어졌어요.
키가 없어요. 누구나 즉시 되돌릴 수 있어요. Base64 로 «가려 둔» 비밀번호는 평문과 같습니다.
용량이 약 33% 늘어요(3바이트가 4문자가 돼요). 큰 파일을 Base64 로 넣으면 그만큼 커진다는 뜻이에요.
URL 에 넣을 때는 `+` 와 `/` 가 문제를 일으켜서 base64url 변형(`-`, `_`)을 써요. JWT 가 그 방식이에요.
`encodeURIComponent` 는 `&`·`=`·`?`·`/` 까지 전부 바꿔요. 쿼리 파라미터 값에 쓰는 함수예요.
`encodeURI` 는 그 문자들을 남겨 둬요. URL 전체를 인코딩할 때 쓰는 함수예요.
값에 `encodeURI` 를 쓰면 값 안의 `&` 가 파라미터 구분자로 오해돼서 데이터가 잘려요. 반대로 URL 전체에 `encodeURIComponent` 를 쓰면 `://` 까지 바뀌어 링크가 죽어요.
공백이 `%20` 이 되기도 `+` 가 되기도 해요 — 전자는 URL 경로, 후자는 폼 전송(`application/x-www-form-urlencoded`) 관례예요.
JWT 는 점으로 나뉜 세 조각이에요: 헤더(알고리즘) · 페이로드(데이터) · 서명.
앞의 두 조각은 그냥 base64url 이에요. 암호화가 아니라 누구나 읽을 수 있어요. JWT 페이로드에 비밀을 넣으면 안 되는 이유예요.
서명은 비밀 키(또는 공개 키)가 있어야 검증돼요. 이 도구는 읽어서 보여줄 뿐 검증하지 않아요 — 키를 브라우저에 넣게 하는 건 그 자체가 위험하니까요.
페이로드의 `exp`(만료)·`iat`(발급)·`nbf`(유효 시작)는 유닉스 초 단위예요. «토큰이 만료됐다» 는 오류를 볼 때 이 값을 사람이 읽는 시각으로 바꿔 보면 원인이 바로 보여요.
다섯 칸이 분 · 시 · 일 · 월 · 요일 이에요. `0 3 * * *` 은 매일 03:00.
자주 틀리는 지점 — 일과 요일을 둘 다 지정하면 OR 로 동작해요. `0 0 1 * 1` 은 «매월 1일 그리고 매주 월요일» 이지 «1일이면서 월요일» 이 아니에요.
`*/15` 는 15분마다지만 0분부터 시작해요(0·15·30·45). 임의의 시점부터 15분 간격이 아니에요.
요일은 0 과 7 이 모두 일요일인 구현이 많아요. 시스템마다 다르니 확인하세요.
⚠️ 시간대를 확인하세요. 서버가 UTC 면 `0 9 * * *` 은 한국 시간 18:00 이에요.
`192.168.1.0/24` 의 `/24` 는 앞 24비트가 네트워크라는 뜻이에요. 나머지 8비트가 호스트라 256개 주소가 나와요.
실제 쓸 수 있는 건 254개예요. 첫 주소는 네트워크 주소, 마지막은 브로드캐스트로 예약돼요.
숫자가 작을수록 범위가 넓어요. `/16` 은 65,536개, `/24` 는 256개, `/32` 는 1개(단일 호스트)예요. 이 방향을 헷갈리는 게 가장 흔한 실수예요.
방화벽·보안그룹 규칙을 쓸 때 `0.0.0.0/0` 은 전 세계 모든 주소예요. SSH 포트에 이걸 열어 두는 건 사고의 출발점이에요.
모든 변환이 브라우저 안에서 처리돼요. 서버로 아무것도 보내지 않아요.
이게 실무에서 중요한 이유 — 개발자가 디코드하려는 JWT 에는 실제 인증 토큰이 들어 있고, 정렬하려는 JSON 에는 고객 데이터가 들어 있어요. 온라인 도구에 그걸 붙여넣는 건 유출 경로가 됩니다.
이 페이지는 그 경로를 만들지 않아요. 네트워크 탭을 열어 확인해 보셔도 됩니다.
헤더와 페이로드를 읽기 쉽게 디코드해 보여주는 용도예요. 서명 검증은 비밀 키가 필요해서 별도 환경에서 해야 해요.
아니요. 전부 브라우저 안에서만 처리되고 어디에도 저장·전송되지 않아요.