HTTP 쿠키 파서

GeekFormat 정보

HTTP Cookie Parser

브라우저가 보낸 Cookie 헤더를 분석합니다. 키-값 쌍, URL 인코딩, 중복 이름 occurrences를 빠르게 확인하세요.

파싱 결과

4 쿠키

#1session

원본 값: abc123

디코딩된 값: abc123

#2theme

원본 값: dark

디코딩된 값: dark

#3locale

원본 값: zh-CN

디코딩된 값: zh-CN

#4callback

원본 값: https%3A%2F%2Fgeekformat.com%2Fdone

디코딩된 값: https://geekformat.com/done

JSON 미리보기

[
  {
    "index": 0,
    "raw": "session=abc123",
    "name": "session",
    "value": "abc123",
    "decodedValue": "abc123"
  },
  {
    "index": 1,
    "raw": "theme=dark",
    "name": "theme",
    "value": "dark",
    "decodedValue": "dark"
  },
  {
    "index": 2,
    "raw": "locale=zh-CN",
    "name": "locale",
    "value": "zh-CN",
    "decodedValue": "zh-CN"
  },
  {
    "index": 3,
    "raw": "callback=https%3A%2F%2Fgeekformat.com%2Fdone",
    "name": "callback",
    "value": "https%3A%2F%2Fgeekformat.com%2Fdone",
    "decodedValue": "https://geekformat.com/done"
  }
]

Cookie 요청 헤더를 전문적으로 분해하며, 속성을 추측하지 않고「이 요청에서 실제로 무엇이 전송되었는지」에만 답합니다.

HTTP 쿠키 파서란 무엇인가요?

HTTP 쿠키 파서는 `Cookie:` 요청 헤더와 `document.cookie` 문자열에 특화된 디버깅 도구입니다. 이것이 해결하는 핵심 문제는「Cookie란 무엇인가」가 아니라, 개발자, 테스트 엔지니어, 크롤러 엔지니어, 운영 담당자가 연동 시 가장 자주 마주하는 실제 시나리오입니다. 즉, 브라우저가 실제로 어떤 쿠키를 전송했는지, 특정 Cookie 값이 URL 인코딩되었는지, 동일한 이름의 쿠키가 중복되지 않았는지, 그리고 현재 Cookie 헤더를 curl, Postman, 스크립트에 그대로 복사하여 문제를 재현하려면 어떻게 해야 하는지입니다.

`Set-Cookie` 응답 헤더와 달리 HTTP 요청 헤더의 Cookie는 플랫한 `name=value` 목록입니다. 이것은「현재 요청에서 실제로 무엇이 전송되었는지」를 알려줄 뿐 SameSite, HttpOnly, Secure, Path, Domain, Expires, Max-Age 등의 속성 정보는 포함하지 않습니다. 그렇기 때문에「API가 로그인 상태를 인식하지 못하는 이유는 무엇인가」「브라우저 요청에 어떤 쿠키가 누락되었는가」「document.cookie의 이 값이 왜 깨져 보이는가」를 조사할 때 요청 헤더 파서는 범용적인 Cookie 도구보다 더 직접적입니다.

이런 종류의 도구에서 가장 흔한 저수준 구현은 단순히 `split(';')`로 문자열을 나누어 렌더링하는 것이지만, 실제 디버깅에서는 나누는 것만으로는 충분하지 않습니다. 값이 URL 인코딩되었는지, 중복된 이름이 존재하는지, 정규화된 헤더 내용을 직접 복사할 수 있는지, 분석 결과를 스크립트나 문서에서 재사용할 수 있는지 알아야 합니다. 현재 페이지는 이러한 개발자의 실제 액션을 중심으로 설계되었습니다.

확인하려는 것이「요청에 무엇이 포함되었는지」가 아니라「서버에서 전달한 Set-Cookie가 왜 브라우저에 거부되었는지」라면, 이 페이지에 머물지 말고 응답 헤더 속성 확인에 더 적합한「Set-Cookie 파서」로 이동하세요. 따라서 이 도구의 포지셔닝은 명확합니다. Cookie 요청 헤더/document.cookie 디버거이며, 응답 헤더 속성 감사 도구가 아닙니다.

사용 사례

로그인 상태 손실이나 세션 이상을 트러블슈팅할 때 요청 헤더에 포함된 쿠키 확인
URL 인코딩된 쿠키를 디버깅할 때 원래 값과 디코딩 값을 비교하여 실제 내용 확인
여러 개의 동일한 이름 쿠키가 브라우저나 서버 처리 이상을 일으키지 않는지 체크
브라우저의 Cookie 헤더를 빠르게 정규화하여 Postman, curl, 스크립트에 복사하고 요청 재현
document.cookie 출력 결과를 분석하여 프론트엔드에서 현재 보이는 쿠키 세트 확인

이용 방법

Cookie 요청 헤더 또는 document.cookie 문자열을 입력 영역에 붙여넣기
각 쿠키의 이름, 원래 값, URL 디코딩 값 확인
중복 이름 알림과 정규화된 Cookie 헤더 결과 확인
정규화 Cookie 헤더를 복사하거나 JSON 미리보기를 확인하여 추가 디버깅 진행

주요 기능

다중 쿠키 자동 분할: 세미콜론으로 구분하여 Cookie 요청 헤더와 document.cookie 문자열을 항목별로 분석
이중 값 표시: 원래 값과 URL 디코딩 값을 동시에 표시하여 인코딩 문제 빠르게 파악
중복 이름 감지: 동일한 이름의 쿠키를 자동으로 식별하고 잠재적 충돌 알림
정규화 출력: 원클릭으로 정규화된 Cookie 요청 헤더를 복사하여 API 디버깅 계속 가능
JSON 미리보기: 분석 결과를 구조화하여 출력, 스크립트, 로그, 테스트 도구에서 활용 가능
로컬 처리: 입력 내용은 브라우저 내에서만 분석되며 서버에 업로드되지 않음

이 페이지와 다른 두 Cookie 도구 중 어떻게 선택하나요?

가지고 있는 것이 요청 헤더, document.cookie, 아니면 서버의 Set-Cookie 응답 헤더인지 먼저 확인한 다음 사용할 페이지를 결정하세요.

도구	적합한 입력	가장 적합한 사용 사례	핵심 강점
HTTP 쿠키 파서(현재 페이지)	Cookie 요청 헤더, document.cookie	요청에 실제로 포함된 쿠키 확인, 값의 인코딩 상태 체크, 중복 이름 감지	요청 헤더 분해, 정규화 복사, URL 디코딩, 중복 감지에 특화
Set-Cookie 파서	서버에서 반환되는 Set-Cookie 응답 헤더	브라우저가 쿠키를 받지 않는 원인 조사, SameSite/Secure/HttpOnly/Path/Domain 리스크 확인	속성 분해가 더 깊이 있으며 보안 설정 알림 제공Set-Cookie 파서 열기
쿠키 파서	Cookie 문자열과 Set-Cookie가 혼합된 디버깅 시나리오	데이터 출처가 불분명하거나 통합 진입점에서 빠르게 분류하고 싶을 때	듀얼 모드 전환을 지원하며 Netscape Cookie File 내보내기 지원쿠키 파서 열기

Best Practices

요청 헤더와 응답 헤더를 혼동하지 마세요

텍스트가 브라우저 DevTools의 Request Headers, 패킷 캡처 도구의 요청, document.cookie, 서버 로그의 Cookie 헤더에서 가져온 것이라면 현재 페이지가 적합합니다. Response Headers의 Set-Cookie에서 가져온 것이라면 여기서 속성 문제를 계속 분석하지 마세요.

원래 값을 보존한 다음 디코딩 값을 확인하세요

Cookie 문제를 조사할 때 디코딩 후 내용만 보지 마세요. 원래 값이야말로 실제 전송 값이며 디코딩 값은 가독성을 위한 보조에 불과합니다. 서명, Base64, JWT, 이중 인코딩 시나리오에서는 원래 값이 특히 중요합니다.

JWT 도구

중복 이름을 발견해도 급히 삭제하지 마세요

중복된 쿠키는 특히 Path/Domain 차이, 환경 전환, 과거 쓰기 잔재 시 문제의 근본 원인일 수 있습니다. 중복 항목을 보존하여 기록한 다음 브라우저 동작과 서버 설정을 대조하세요.

요청을 재현할 때는 정규화 헤더를 우선 복사하세요

현재 Cookie 헤더를 curl, Postman, 테스트 스크립트에 전달하여 재현해야 할 때 정규화된 결과를 직접 복사하면 불필요한 공백, 줄바꿈, 포맷 노이즈로 인한 재현 편차를 줄일 수 있습니다.

curl 코드 변환

자주 묻는 질문

이 페이지는 어떤 Cookie 입력을 분석하는 데 적합한가요?

Cookie 요청 헤더와 `document.cookie` 형식의 플랫 문자열(예: `session=abc123; theme=dark`) 분석에 특화되어 있습니다. 서버에서 반환되는 `Set-Cookie` 응답 헤더를 가지고 계신 경우, 함께 제공되는「Set-Cookie 파서」로 전환해 주세요. 요청 헤더의 Cookie에는 SameSite, HttpOnly, Secure, Path, Domain 등의 속성 정보가 포함되지 않기 때문입니다.

Set-Cookie 파서

Cookie 값이 깨져 보이는 이유는 무엇인가요?

많은 Cookie 값은 URL 인코딩되어 있습니다. 예를 들어 `%3D`는 `=`, `%2F`는 `/`를 나타냅니다. 이 도구는 원래 값과 URL 디코딩 후의 값을 모두 표시하므로, 읽기 어려운 인코딩 문자열만 보는 것이 아니라 실제 내용을 빠르게 확인할 수 있습니다.

중복된 Cookie 이름을 감지하는 이유는 무엇인가요?

동일한 이름의 쿠키는 서로 다른 Path, 서로 다른 Domain, 또는 과거 쓰기 잔재로 인해 발생할 수 있습니다. 요청 헤더에서는 플랫한 `name=value`의 나열에 불과하지만, 중복된 이름은 브라우저 동작이나 서버 측 처리에 불일치를 일으키는 경우가 많으므로 도구는 조용히 덮어쓰지 않고 적극적으로 알려줍니다.

로그인 상태와 세션 문제 트러블슈팅에 적합한가요?

적합합니다. 브라우저 요청에서 실제로 전송되고 있는 Cookie 헤더를 붙여넣으면 각 쿠키의 이름, 원래 값, 디코딩된 값을 한눈에 확인할 수 있어, 특정 세션 필드가 누락되지 않았는지, 값이 올바르게 인코딩되었는지, 동일한 이름의 쿠키가 혼란을 일으키고 있지 않은지 빠르게 파악할 수 있습니다.

분석 결과를 API 디버깅에 직접 사용할 수 있나요?

네. 도구는 정규화된 Cookie 헤더를 생성하므로 curl, Postman, 스크립트, API 디버깅 플랫폼에 원클릭으로 복사하여 문제를 재현할 수 있습니다. 또한 로그, Issue, 테스트 케이스 기록용으로 JSON 미리보기도 지원합니다.

왜 이 페이지에는 SameSite, HttpOnly, Secure가 표시되지 않나요?

이러한 속성은 `Set-Cookie` 응답 헤더에만 존재하며, 브라우저가 이후 전송하는 `Cookie` 요청 헤더에는 포함되지 않습니다. 현재 페이지는「요청 시 실제로 무엇이 전송되었는지」에 초점을 맞추고 있으며,「서버가 처음에 무엇을 설정했는지」가 아닙니다.

document.cookie와 Cookie 요청 헤더는 같은 것인가요?

둘은 매우 비슷하며 모두 `name=value; name2=value2`의 플랫한 구조이지만 차이도 있습니다. `document.cookie`에서는 HttpOnly 쿠키를 읽을 수 없지만, 요청 헤더의 Cookie는 브라우저가 현재 스코프에 따라 자동으로 붙이는 최종 세트입니다. 이 파서는 두 가지 유형의 플랫한 입력을 모두 처리하는 데 적합합니다.

붙여넣은 Cookie가 서버에 업로드되나요?

아니요. 현재 페이지의 분석, URL 디코딩, 중복 감지, JSON 미리보기는 모두 브라우저 로컬에서 완료되며, Session, Token, 로그인 상태 쿠키나 사용자 데이터가 어떤 서버로도 전송되지 않습니다.

용어집

Cookie 요청 헤더: 브라우저가 HTTP 요청에서 자동으로 전송하는 쿠키 이름-값 쌍의 집합으로, 일반적으로 `name1=value1; name2=value2` 형식입니다. 현재 요청에서 실제로 전송된 쿠키를 반영하며 보안 속성은 포함하지 않습니다.Set-Cookie 파서
document.cookie: 프론트엔드 JavaScript가 읽을 수 있는 쿠키 문자열 인터페이스입니다. 일반적으로 요청 헤더의 Cookie와 구조는 비슷하지만 HttpOnly 쿠키를 읽을 수 없으며, 완전한 Set-Cookie 설정을 역추론할 수도 없습니다.
URL 인코딩된 Cookie 값: 특수 문자를 안전하게 전송하기 위해 퍼센트 인코딩된 Cookie 값으로, 예를 들어 `%3D`, `%2F`, `%3A` 등이 있습니다. 디버깅 시에는 원래 값과 디코딩 후의 값을 모두 확인하는 것이 일반적입니다.URL Encode 도구
중복된 Cookie 이름: 동일한 요청 헤더 내에 동일한 이름의 쿠키가 여러 개 존재하는 것입니다. 서로 다른 Path, 서로 다른 Domain, 또는 오래된 값의 잔재로 인해 발생할 수 있으며, 세션 이상과 동작 불일치의 중요한 단서가 되는 경우가 많습니다.
정규화된 Cookie 헤더: 입력 내용을 정제하여 다시 조합한 표준적인 `name=value; name2=value2` 문자열로, curl, 스크립트, Postman, 로그에 복사하여 문제를 재현하기 쉽게 만든 것입니다.

Cookie 요청 헤더와 Set-Cookie 응답 헤더 비교표

Cookie 디버깅 오해의 대부분은 요청 헤더와 응답 헤더를 섞어서 보는 것에서 비롯됩니다.

비교 항목	Cookie 요청 헤더	Set-Cookie 응답 헤더
출현 위치	브라우저에서 서버로의 요청 내	서버에서 브라우저로의 응답 내
일반적인 형식	name1=value1; name2=value2	name=value; Path=/; HttpOnly; Secure
속성 포함 여부	포함하지 않음	SameSite/Path/Domain/Expires/Max-Age 등 포함
조사에 적합한 내용	요청에 실제로 무엇이 포함되었는지	브라우저가 쿠키를 받지 않는 이유
더 적합한 도구	현재 페이지	Set-Cookie 파서

Cookie 요청 헤더 디버깅 빈발 문제 대조표

가지고 있는 것이 요청 헤더 Cookie일 때 이러한 문제가 가장 자주 발생합니다.

증상	높은 확률의 원인	우선 확인 사항
API가 로그인 상태를 인식하지 못함	요청에 대상 쿠키가 포함되지 않았거나 이름과 값이 일치하지 않음	정규화된 Cookie 헤더에 대상 세션 필드가 있는지 먼저 확인
Cookie 값이 깨져 보임	값이 URL 인코딩됨	원래 값과 디코딩 값을 동시에 비교
환경마다 동작이 다름	중복된 Cookie 이름, 이전 값 잔재, 브라우저 스코프 선택 차이	중복 이름 알림을 확인하고 모든 동명 항목을 기록
스크립트에서 재현 실패	복사 시 불필요한 공백, 줄바꿈, 포맷 노이즈 혼입	정규화된 Cookie 헤더를 사용하여 다시 복사

Privacy & Security

Cookie 요청 헤더 분석, URL 디코딩, 중복 감지, JSON 미리보기는 모두 브라우저 로컬에서 완료됩니다. 입력된 Session, Token, 로그인 상태 쿠키는 어떤 서버에도 업로드되지 않습니다.