글을 URL 주소로 변환 소문자, 붙임표, 발음 부호 없이 무료 온라인 안전
한 줄 붙여 넣으면 바로 URL 주소로 읽힙니다. 모두 여러분의 브라우저 안에서 일어나고, 입력한 것은 어디로도 보내지지 않으며, 규칙은 영어가 아니라 이 쪽의 언어를 따릅니다.
다르게 써 보기
업로드 없음
같은 줄을, 일곱 가지 표기 모두로
| 표기 | 같은 줄을, 그 표기로 |
|---|---|
| 대문자 | CRÈME BRÛLÉE 2인분 — STRASSE 17, FOOBAR |
| 소문자 | crème brûlée 2인분 — straße 17, foobar |
| Title Case | Crème Brûlée 2인분 — Straße 17, Foobar |
| snake_case | crème_brûlée_2인분_straße_17_foo_bar |
| kebab-case | crème-brûlée-2인분-straße-17-foo-bar |
| camelCase | crèmeBrûlée2인분Straße17FooBar |
| URL 주소 | creme-brulee-2인분-strasse-17-foobar |
이 표기 형식은 어디에서 왔는가
큰 글자와 작은 글자는 한때 서로 다른 두 벌의 글자였습니다. 큰 글자는 로마의 것으로 끌로 돌에 새겼고, 작은 글자는 양피지 위를 빠르게 달린 붓이 빚어낸 카롤링 소문자에서 내려왔습니다. 인쇄공들은 둘을 서로 다른 활자 상자에 두었고 — 윗상자와 아랫상자 — 상자가 사라진 뒤로도 그 이름만은 오래 남았습니다. 프로그래밍의 형식들은 훨씬 젊고, 단 하나의 문제를 풀려고 지어졌습니다. 이름에는 빈칸이 들어갈 수 없다는 문제입니다. snake_case는 초기 C에서, camelCase는 Smalltalk에서, kebab-case는 Lisp에서, 그리고 주소의 슬러그는 빈칸과 덧붙임표가 허용되지 않는 주소에 사람이 읽을 제목을 넣어야 할 필요에서 나왔습니다.
어디에서 마주치는가
낱말마다 큰 글자로 쓰는 방식은 제목과 책 표지의 것입니다. 문장처럼 쓰는 방식은 나머지 거의 전부의 것이고, 읽기가 빨라 화면의 표시에도 점점 퍼지고 있습니다. snake_case는 데이터베이스 열과 파이썬 변수에 이름을 주고, camelCase는 자바스크립트 변수와 자바 메서드에, kebab-case는 CSS 클래스와 웹 프로젝트의 파일 이름에 줍니다. 슬러그는 글의 제목을 주소의 마지막 부분으로 바꾸는 것이며, 여기 있는 변환 가운데 검색 엔진이 읽는 것은 그것뿐입니다.
자주 묻는 질문
큰 글자로 바꾸면 왜 때때로 글자 수가 달라지나요?
글자의 크기 구분은 글자 자체가 아니라 언어의 성질이기 때문입니다. 독일어 ß는 큰 글자로 SS가 되어 한 글자가 둘이 됩니다. 터키어에는 점 있는 i와 점 없는 i가 있고, i의 큰 글자는 I가 아니라 İ입니다. 여기서 틀리면 터키어 낱말이 다른 낱말이 되고 맙니다. 이 쪽의 변환은 각 쪽의 언어 규칙을 따르므로, 같은 입력이라도 터키어 쪽과 영어 쪽에서 결과가 다를 수 있습니다.
슬러그는 왜 덧붙임표와 문장 부호를 없애나요?
주소는 메시지에 복사되고 종이에 인쇄되고 손으로 다시 입력되는 일을 견뎌야 하기 때문입니다. 덧붙임표가 붙은 글자는 요즘 주소에서도 허용되지만 복사할 때 백분율로 부호화되어, 읽히던 주소가 기호의 행렬로 바뀝니다. 그것을 민 글자와 숫자와 붙임표까지 깎아 내면 주소는 읽히고, 나누기 좋고, 어디에 나타나든 똑같은 모습으로 남습니다.
답이 정확한가요?
두 단위가 정수로 서로 정의되어 있으면 정확합니다 — 쪽에서 숫자 위에 그렇게 밝히고 있고, 반올림은 몇 자리를 보여 주느냐에만 있습니다. 비가 유한소수가 아닐 때는 유효숫자 열두 자리를 보여 주고 관계가 근사라고 말합니다. 아닌 척하지 않습니다.
제가 입력한 것이 기기 밖으로 나가나요?
아니요. 계산은 여러분의 브라우저 안에서 이루어집니다. 아무것도 올라가지 않고, 올릴 서버도 없습니다. 한 번 불러오면 네트워크를 꺼도 동작합니다.
텍스트를 URL 슬러그로 변환하는 이유
웹의 모든 페이지에는 주소가 있고, 그 주소의 마지막 조각은 보통 몇 개의 단어입니다. how-to-repot-a-fern, annual-report-2026, contact-us 같은 것들입니다. 그 조각이 슬러그입니다. URL의 사람이 읽을 수 있는 꼬리이며, 페이지가 로드되기도 전에 독자와 검색 엔진에게 페이지가 무엇에 관한 것인지 알려 주는 부분입니다. 글, 제품, 카테고리, 파일을 게시할 때 누군가는 정식 제목을 그 꼬리로 바꿔야 합니다. 텍스트를 URL 슬러그로 변환한다는 것은 대문자, 공백, 쉼표, 악센트가 있는 채로 사람이 쓴 제목을, 어떤 서버, 브라우저, 링크 검사기도 불평 없이 받아들이는, 하이픈으로 이은 소문자 단어로 줄이는 일입니다.
제목을 붙여 넣고 슬러그로 읽어 보십시오. 변환은 브라우저 안에서 실행되고, 입력하는 내용은 어디로도 전송되지 않으며, 한 번의 클릭으로 결과를 복사할 수 있습니다. 아래에서는 페이지가 한 줄에 정확히 무엇을 하고 무엇을 그대로 두는지, 악센트가 붙은 글자와 다른 알파벳의 글자를 어떻게 다루는지, 손으로 다시 확인해야 할 결과, 슬러그가 중요한 곳과 그렇지 않은 곳, 그리고 서둘러 텍스트를 URL 슬러그로 변환하는 사람들이 걸려드는 함정을 설명합니다.
변환이 하는 일
소문자로, 표시를 벗기고, 하이픈으로
페이지는 세 가지 동작으로 일합니다. 줄을 소문자로 바꿉니다. 라틴 글자에서 악센트와 다른 표시를 벗겨 내므로 é는 e가 되고 ü는 u가 됩니다. 그런 다음 글자나 숫자가 아닌 모든 것을 하이픈으로 바꾸고 반복된 하이픈을 하나로 줄입니다. Crème Brûlée for 2 — Straße 17, fooBar라는 줄은 creme-brulee-for-2-strasse-17-foobar로 돌아옵니다. 쉼표, 대시, 공백은 모두 하이픈 하나가 되었고, 악센트는 사라졌으며, ß는 ss가 되었고, 숫자는 제자리에 남았습니다.
하이픈은 쌓이지도, 끝에 붙지도 않습니다
Hello, World!처럼 문장 부호로 끝나는 제목에서 단순한 치환은 끝에 하이픈이 매달려 남게 합니다. 페이지는 양 끝의 하이픈을 다듬고 연속된 하이픈을 합쳐서, 결과가 hello-world- 나 hello--world가 아니라 hello-world가 되게 합니다. 이는 보기보다 중요합니다. 끝의 하이픈은 주소를 엉성해 보이게 하고, 이중 하이픈은 누군가 메시지에 복사해 넣을 때 링크를 깨뜨릴 수 있습니다.
결과 복사하기
결과 옆의 버튼이 클립보드로 복사해 줍니다. 게시 시스템의 슬러그 칸, 파일 이름, 또는 손으로 만들고 있는 주소의 끝에 붙여 넣으십시오.
변환이 하지 않는 일
다른 알파벳을 음역하지 않습니다
표시는 라틴 글자에서만 벗겨집니다. 일본어, 아랍어, 그리스어, 힌디어로 된 제목은 자기 글자를 유지하는데, 페이지가 그 글자의 라틴 철자를 짐작하지 않기 때문입니다. 음역은 언어와 출판사마다 다른 관례에 달려 있으며, 잘못된 짐작은 그럴듯해 보이지만 잘못 읽히는 슬러그를 만듭니다. 그런 알파벳의 글자도 글자로 치므로 그대로 남고, 주소에 나타날 때 브라우저가 퍼센트 인코딩을 합니다. 사이트가 그런 제목에도 라틴 글자만의 주소를 원한다면 음역을 직접 쓴 다음 음역된 줄을 변환하십시오.
모든 알파벳의 모든 표시를 벗기지는 않습니다
라틴 알파벳 밖의 일부 글자는 글자 자체에 속하는 표시를 지닙니다. 러시아어 й와 우크라이나어 ї가 그 예입니다. 표시가 글자를 쓰는 방식의 일부이므로 페이지는 그대로 둡니다. 힌디어 모음 부호 같은 글자에도 같은 논리가 적용됩니다. 라틴 글자 위에 얹힌 악센트만 제거됩니다.
결과를 줄이지 않습니다
긴 제목은 긴 슬러그가 됩니다. 페이지는 the, of, and 같은 작은 단어를 빼지 않으며 정해진 길이에서 자르지도 않습니다. 더 짧은 주소를 원한다면 먼저 제목을 줄이십시오. 의미 있는 네 개에서 여섯 개 단어의 슬러그가 표제 전체를 되풀이하는 슬러그보다 검색 결과에서 더 잘 읽힙니다.
슬러그가 비어 있는지 확인하지 않습니다
서로 다른 두 글이 같은 슬러그를 줄 수 있습니다. 어떤 슬러그가 이미 쓰이고 있는지 아는 곳은 게시 시스템뿐이므로, 확정하기 전에 거기서 확인하십시오.
다시 한번 살펴볼 글자
독일어 ß와 움라우트
날카로운 s는 ss가 되므로 Straße는 strasse가 됩니다. 움라우트는 점을 잃으므로 Müller는 muller가 됩니다. 일부 독일어 출판사는 발음을 유지하는 mueller를 선호합니다. 독자가 e가 들어간 철자로 검색한다면 변환하기 전에 제목을 그렇게 쓰십시오.
스칸디나비아와 폴란드의 글자
사선이 있는 o는 평범한 o가 되므로 Ørsted는 orsted가 되고, 폴란드어 ł는 l이 되므로 Łódź는 lodz가 됩니다. Å와 ä는 표시를 잃고 a가 됩니다. 대부분의 사람이 기대하는 결과이지만, 지역의 자부심이 담긴 이름은 손으로 다르게 처리할 만할 수 있습니다.
튀르키예어의 점 있는 i와 점 없는 i
소문자 변환은 페이지의 언어를 따릅니다. 튀르키예어에서 İ는 i로, I는 ı로 소문자가 되며, ı는 그대로 독립된 글자로 남습니다. 영어 규칙을 적용하는 변환기는 모든 대문자 I를 i로 바꿔 단어를 바꿔 놓습니다. 이 페이지는 쓰인 언어를 따릅니다.
루마니아어, 프랑스어, 스페인어의 악센트
글자 ă, â, î, ș, ț는 a, a, i, s, t가 됩니다. 프랑스어에서 é, è, ê, ç는 e와 c를 줍니다. 스페인어에서 ñ는 n을 주는데, 여기서 슬러그의 뜻이 바뀔 수 있습니다. 한 해를 뜻하는 año와 다른 것을 뜻하는 ano가 같은 문자열로 합쳐집니다. 표제가 이 차이를 가지고 말장난을 할 때는 이를 염두에 두십시오.
베트남어의 겹쳐진 표시
베트남어 글자는 한꺼번에 두 개의 표시를 지닐 수 있습니다. 둘 다 벗겨지고 đ는 d가 되어 Hà Nội는 ha-noi가 됩니다. 베트남어 화자에게는 읽을 수 있는 결과이지만 성조는 사라집니다.
슬러그가 그런 모양인 이유
주소는 대소문자를 구분할 수 있으므로 소문자
주소의 경로 부분은 많은 서버에서 대소문자를 구분합니다. /About과 /about은 서로 다른 두 페이지일 수도 있고, 한 페이지와 하나의 오류일 수도 있습니다. 모든 슬러그를 소문자로 쓰면 이 문제가 사라집니다. 검색 엔진도 둘을 별개의 주소로 취급하므로, 대소문자를 섞으면 한 페이지가 두 개의 사본으로 갈라질 수 있습니다.
하이픈은 공백으로 읽히므로
검색 엔진은 하이픈을 단어 구분자로, 밑줄을 이어 주는 글자로 취급합니다. 하이픈이 있는 슬러그는 별개의 단어로 읽히며, 그 단어들로 순위를 얻으려면 바로 그것이 필요합니다. 웹 주소가 kebab-case를 선호하고 밑줄 형태인 snake_case가 주소가 아니라 코드와 데이터베이스에 속하는 이유입니다.
특수 문자는 인코딩해야 하므로 없음
공백, 쉼표, 물음표, 앰퍼샌드, 슬래시는 모두 주소 안에서 의미가 있습니다. 물음표는 쿼리 문자열을 시작하고, 슬래시는 경로의 새 단계를 시작합니다. 자기만의 의미가 있는 문자를 평문으로 쓰려면 퍼센트 인코딩을 해야 하며, %20과 %C3%A9로 가득한 슬러그는 보기 흉하고 깨지기 쉽습니다. 글자, 숫자, 하이픈만 쓰면 이 문제 전체를 피할 수 있습니다.
모든 도구가 감당하지는 못하므로 악센트 없음
최신 브라우저는 악센트가 있는 주소를 잘 보여 주지만, 같은 주소가 이메일, 채팅 메시지, 인쇄된 보고서에서는 퍼센트 기호의 나열로 도착할 수 있습니다. 일반 글자는 모든 여정을 견뎌 냅니다. 라틴 글자의 표시를 제거하는 가장 강력한 이유이며, 거의 모든 게시 시스템이 기본으로 그렇게 하는 까닭을 설명해 줍니다.
깨끗한 슬러그가 중요한 곳
블로그 글과 기사
블로그에서는 텍스트를 URL 슬러그로 변환하는 것이 모든 게시 절차의 일부입니다. 글의 슬러그는 사람들이 클릭하기 전에 검색 결과, 공유된 링크, 브라우저 탭에서 읽습니다. 제목과 일치하는 슬러그는 믿음이 갑니다. 숫자의 나열인 슬러그는 독자에게 아무것도 알려 주지 않습니다. 많은 콘텐츠 시스템이 제목에서 슬러그를 자동으로 만들지만, 자동 버전은 너무 길거나 시간이 지나도 유효해야 할 글을 낡아 보이게 하는 날짜를 담을 수 있어서 손으로 고치는 일이 흔합니다.
제품과 카테고리 페이지
상점에는 수천 개 항목의 슬러그가 필요하므로 텍스트를 URL 슬러그로 거듭 변환합니다. 브랜드, 제품 이름, 크기를 그 순서로 두는 것 같은 일관된 규칙은 카탈로그를 깔끔하게 유지하고 주소를 예측 가능하게 만듭니다. 모든 제품 줄을 같은 페이지, 곧 한 번에 텍스트를 URL 슬러그로 변환할 수 있게 해 주는 페이지로 변환하면 패턴이 힘들이지 않고 유지됩니다.
다운로드용 파일 이름
Final Report (v2) copy.pdf라는 파일은 주소에서 문제를 일으킵니다. final-report-v2.pdf라는 파일은 그렇지 않습니다. 다운로드를 게시한다면 슬러그 규칙은 좋은 파일 이름 규칙이기도 합니다. 도중에 형태가 바뀌어야 하는 문서에는 HTML을 PDF로 변환 같은 변환기가 이름과 내용을 여러분의 통제 아래 둡니다.
앵커와 페이지 안의 링크
주소에서 해시 기호 뒤의 부분은 페이지 안의 한 위치를 가리킵니다. 제목은 흔히 같은 규칙으로 앵커 ID가 됩니다. 소문자, 하이픈, 표시 없음입니다. 긴 문서의 목차를 손으로 쓴다면 각 제목을 슬러그로 변환하여 생성기가 만들어 낼 것과 일치하는 ID를 얻을 수 있습니다.
Git 브랜치와 식별자
브랜치 이름, 이슈 라벨, 폴더 이름은 주소와 같은 제한에 직면합니다. Add user login이라는 기능은 add-user-login이 됩니다. 하이픈 대신 대문자가 필요한 코드 식별자에는 camelCase가 형제 형태입니다.
여기서 텍스트를 URL 슬러그로 변환하는 방법
제목을 붙여 넣거나 입력
텍스트를 URL 슬러그로 변환하려면 첫 번째 칸에 제목을 입력하십시오. 입력하는 동안 슬러그가 두 번째 칸에 나타나므로 문장 부호가 하나씩 사라지는 모습을 지켜볼 수 있습니다.
바뀐 것 읽기
하이픈이 어디에 놓였는지 보고 모든 단어가 살아남았는지 확인하십시오. 단어가 빠졌다면 페이지가 그대로 두는 글자로 이루어져 있었거나, 하이픈이 된 문자로 분리되어 있었을 것입니다. 둘 다 눈으로 금방 알아볼 수 있습니다.
제자리에 복사
복사 버튼을 누르고 필요한 곳에 슬러그를 붙여 넣으십시오. 게시 시스템도 슬러그를 소문자로 바꾸고 정리한다면 결과가 변하지 않고 통과할 것이며, 이는 둘이 일치한다는 좋은 신호입니다.
같은 줄의 나머지 여섯 가지 형태
비교용 표 하나
변환기 아래의 표는 예시 줄을 사이트가 제공하는 일곱 가지 형태로 모두 보여 줍니다. 대문자, 소문자, Title Case, snake_case, kebab-case, camelCase, URL 슬러그입니다. 나란히 비교하는 것이 어느 것이 어디에 속하는지 보는 가장 빠른 방법입니다. 단어만 소문자로 하고 다른 것은 바꾸지 않으려면 소문자가 평범한 선택이고, 사람이 읽을 제목에는 Title Case를 쓰십시오.
슬러그는 어디서 왔을까
신문사에서 온 말
슬러그라는 말은 웹보다 오래되었고, 텍스트를 URL 슬러그로 손으로 변환해야 하는 습관도 그렇습니다. 인쇄소에서는 연필로 했습니다. 인쇄 신문사에서 슬러그는 기사가 건물 안을 오가는 동안 붙여 두는 짧은 라벨로, 편집자와 식자공에게 어느 기사가 어느 기사인지 알려 주는 몇 단어였습니다. 콘텐츠 관리 시스템은 각 페이지에 짧은 라벨이 필요해지자 이 이름을 빌렸습니다. 일은 같습니다. 하나의 항목을 모호함 없이 식별하는 몇 개의 쉬운 단어입니다.
쿼리 문자열에서 읽기 쉬운 경로로
초기의 동적 사이트는 page.php?id=4731 같은 주소를 썼습니다. 작동은 했지만 아무도 읽을 수 없었습니다. 사람들이 클릭하기 전에 링크를 판단하고 검색 엔진이 그 안의 단어에 비중을 둔다는 사실이 분명해지자 읽기 쉬운 경로가 뒤따랐습니다. 오늘날 거의 모든 게시 도구가 슬러그를 생성하며, 규칙이 어떻게 작동하는지 알면 고쳐야 할 결과를 알아보는 데 도움이 됩니다.
더 넓은 작업 흐름 속의 슬러그
제목 스프레드시트에서 주소 목록으로
사이트 이전은 흔히 스프레드시트로 시작합니다. 제목의 열과 옛 주소의 열입니다. 새 주소는 제목에서 나옵니다. 각 제목을 같은 규칙으로 변환하면 새 열은 첫 행부터 마지막 행까지 일관됩니다. 시트가 다른 시스템을 위한 데이터로 나가야 할 때는 CSV를 JSON으로 변환이 행을 레코드로 바꿔 주고, JSON을 CSV로 변환이 검토를 위해 다시 가져옵니다.
리디렉션 계획
이미 있는 페이지를 위해 텍스트를 URL 슬러그로 변환할 때는, 페이지의 슬러그가 바뀌면 옛 주소가 새 주소로 리디렉션되어야 하며 그렇지 않으면 들어오는 모든 링크가 깨진다는 점을 기억하십시오. 옛 제목과 새 제목을 모두 변환하여 두 슬러그를 나란히 놓으면 짐작 없이 리디렉션 목록이 나옵니다. 목록을 보관하십시오. 리디렉션은 유지하기는 싸고 잃으면 비쌉니다.
디자인과 주소를 일치시키기
이름 짓기는 프로젝트 전체에 걸쳐 중요합니다. 디자인 파일의 Primary Button이라는 컴포넌트, 스타일시트의 primary-button이라는 클래스, 페이지 /buttons/primary-button은 모두 같은 것을 가리킵니다. 이름이 하나의 규칙을 따르면 도구들을 가로질러 검색해도 모든 것이 나옵니다. 그 컴포넌트에 딸려 오는 치수에는 px를 rem으로 변환이 이름을 일관되게 유지한 채 크기를 변환합니다.
좋은 슬러그가 되는 제목 쓰기
핵심 단어를 앞에
슬러그는 왼쪽에서 오른쪽으로 읽히며, 앞의 단어가 가장 큰 비중을 갖습니다. 제목을 a, the, how 같은 군더더기가 아니라 주제로 시작하십시오. 주제로 시작하는 제목은 주제로 시작하는 슬러그를 줍니다.
짧게 유지
텍스트를 URL 슬러그로 변환하기 전에 제목을 다듬으십시오. 네 개에서 여섯 개의 단어가 좋은 목표입니다. 긴 슬러그는 검색 결과에서 잘리고 인쇄물에서도 어색합니다. 제목이 길다면 슬러그용으로 더 짧은 버전을 써서 그 줄을 대신 변환하십시오.
날짜가 있는 내용이 아니라면 날짜는 피하기
슬러그 속의 연도는 페이지를 낡게 합니다. 뉴스에는 날짜가 의미가 있습니다. 최신으로 유지할 생각인 안내문에는 빼 두면 내용을 새로 고쳐도 주소가 유효하게 유지됩니다.
키워드를 채워 넣지 않기
텍스트를 URL 슬러그로 변환할 때 용어를 가득 채우고 싶은 충동을 억누르십시오. 같은 단어를 세 번 되풀이하는 슬러그는 스팸처럼 보이고 얻는 것이 없습니다. 한 번, 분명하게 말하십시오.
규칙을 정해 그대로 지키기
텍스트를 URL 슬러그로 변환할 때마다 같은 페이지와 같은 습관을 쓰십시오. 규칙이 무엇이든 어디에나 적용하십시오. 일관된 주소는 링크하고, 리디렉션하고, 분석하고, 기억하기가 더 쉽습니다.
텍스트를 URL 슬러그로 변환할 때의 함정
빈 결과
페이지가 그대로 두는 글자로만 이루어졌거나, 모두 하이픈이 되는 문자로만 이루어진 제목은 비어 있거나 이상하게 짧게 돌아올 수 있습니다. 결과가 비어 있다면 입력에 페이지가 라틴 글자나 숫자로 인식하는 것이 없었다는 뜻입니다. 제목의 라틴 글자 버전을 제공하십시오.
다른 제목, 같은 슬러그
Résumé와 Resume는 같은 슬러그를 주며, Año와 Ano도 그렇습니다. 게시 시스템은 대개 두 번째 것에 숫자를 붙이는데, 이는 주소의 의미를 떨어뜨립니다. 그런 일이 생기면 알아차리고, 둘이 중요하다면 제목을 다시 쓰십시오.
공개된 슬러그 바꾸기
슬러그는 페이지에 링크를 건 모든 사람에 대한 약속의 일부입니다. 리디렉션 없이 바꾸면 그 약속이 깨집니다. 게시하기 전에 슬러그를 정하고, 나중에 꼭 바꿔야 한다면 같은 날 리디렉션을 추가하십시오.
개인 정보가 들어 있는 슬러그
주소 안의 이름, 이메일 주소, 주문 번호는 서버 로그, 브라우저 기록, 공유된 링크에 남습니다. 제목에 사적인 내용이 들어 있다면 그대로 슬러그로 만들지 마십시오.
페이지와 서버가 일치한다고 가정하기
게시 시스템은 붙여 넣은 어떤 슬러그 위에도 자체 규칙을 적용할 수 있습니다. 저장한 뒤 최종 주소를 확인하십시오. 기대한 것과 다르다면 알아 두어야 할 규칙이 시스템에 있는 것입니다.
변환 전의 질문
숫자는 어떻게 되나요?
옆에 있던 단어의 일부로, 또는 하이픈 사이의 별개 단어로 남습니다.
대문자는 유지되나요?
아니요. 페이지의 언어를 따라 모두 소문자가 됩니다.
슬러그가 주소 전체와 같은가요?
아니요. 슬러그는 경로의 마지막 조각입니다. 도메인과 그 앞의 폴더는 사이트가 정합니다.
하이픈 대신 밑줄을 써도 되나요?
쓸 수는 있지만 주소에는 하이픈이 표준인데, 검색 엔진이 하이픈을 공백으로 읽기 때문입니다. 코드에는 snake_case를 보십시오.
제 텍스트가 어딘가에 업로드되나요?
아니요. 변환은 브라우저 안에서 이루어집니다. 초안 제목, 고객 이름, 출시 전 제품도 텍스트 편집기에서만큼 비공개입니다.
제 언어에 라틴 글자가 없다면요?
글자는 그대로 남고 브라우저가 주소에서 인코딩합니다. 최신 브라우저가 올바르게 표시하므로 많은 사이트가 그런 주소를 그대로 유지합니다. 라틴 글자 버전이 필요하다면 직접 써서 그것을 변환하십시오.
실제 사용 예
작은 베이커리 사이트를 운영하며 세 페이지를 게시한다고 해 봅시다. Crème Brûlée for Two, Sourdough Starter: Notes for Beginners, Müsli & Granola — 2026 Prices입니다. 하나씩 붙여 넣습니다. 첫 번째는 creme-brulee-for-two를 줍니다. 두 번째는 sourdough-starter-notes-for-beginners를 주는데 너무 길다고 판단해서 제목을 Sourdough Starter Basics로 줄여 다시 변환하면 sourdough-starter-basics가 됩니다. 세 번째는 musli-granola-2026-prices를 줍니다. 페이지가 갱신될 것이므로 연도를 빼고 musli-granola-prices로 정합니다. 슬러그 세 개, 모두 소문자이고 모두 하이픈으로 이어졌으며 표시나 기호는 없습니다. 이 모든 일은 잠깐이면 끝났고, 중요했던 결정, 곧 연도를 뺀 것은 페이지가 아니라 여러분의 몫이었습니다.
간단한 점검표
변환 전
제목을 쉬운 말로 쓰십시오. 주제를 앞에 두십시오. 필요 없는 날짜는 빼십시오. 더 짧은 버전이 나을지 정하십시오.
변환 중
하이픈을 지켜보십시오. 사라진 단어가 없는지 확인하고, 악센트가 붙은 글자와 특수한 글자가 어떻게 처리되었는지 보십시오.
변환 후
슬러그가 이미 쓰이고 있지 않은지, 소리 내어 읽어도 말이 되는지, 시스템의 최종 주소가 일치하는지 확인하십시오. 공개된 슬러그를 바꾼다면 리디렉션을 추가하십시오.
텍스트는 기기에 머뭅니다
변환은 로컬에서 이루어집니다. 브라우저가 텍스트를 처리하며 아무것도 업로드, 저장, 전송되지 않습니다. 만들어야 할 계정도, 나중에 지울 것도 없습니다. 초안 제목을 낯선 사람에게 넘기지 않고 텍스트를 URL 슬러그로 변환하는 간단한 방법입니다.
요약
여기서 텍스트를 URL 슬러그로 변환하려면 제목을 붙여 넣고, 소문자로 바뀌고, 라틴 글자의 표시가 벗겨지고, 다른 모든 문자가 하이픈으로 바뀌고, 반복된 하이픈이 하나로 줄어든 결과를 읽으면 됩니다. 페이지는 일본어, 아랍어, 그리스어를 음역하지 않고, 러시아어 й 같은 글자에 속한 표시를 벗기지 않으며, 줄이거나 중복을 확인하지도 않으므로 그런 결정은 여러분의 몫으로 남습니다. ß, ø, ł 같은 글자는 ss, o, l이 되고, 소문자 변환은 페이지의 언어를 따르므로 튀르키예어 İ는 튀르키예어로 처리됩니다. 아무것도 업로드되지 않습니다.