HAR 會記錄你登入後的 cookie 和 token，拿到它的人可以直接用你的身分登入。先在這裡清掉再送出。
把 .har 檔拖到這裡
從瀏覽器 DevTools 匯出的 .har 或 .json，也可以點一下選檔。只在這個分頁裡讀取，不會上傳。
或直接貼上 HAR 的 JSON
想一次檢查好幾種檔案？ 改用檔案 metadata 檢查
把 DevTools 匯出的 .har 丟進來，看清楚裡面帶了哪些 cookie、Authorization、token、JWT 和私鑰，再下載一份把值換掉的副本——然後才交給客服、才貼進 issue。
檔案不會離開你的瀏覽器 — 全部在本機處理。
HAR 會記錄你登入後的 cookie 和 token，拿到它的人可以直接用你的身分登入。先在這裡清掉再送出。
把 .har 檔拖到這裡
從瀏覽器 DevTools 匯出的 .har 或 .json，也可以點一下選檔。只在這個分頁裡讀取，不會上傳。
想一次檢查好幾種檔案？ 改用檔案 metadata 檢查
客服說「請匯出一份 HAR 檔給我們」的時候，你交出去的其實是瀏覽器這段時間所有請求的完整錄影：網址、header、cookie、請求與回應的內文，全部都在。裡面有讓你維持登入狀態的 session cookie、你的 app 每一次呼叫都會帶的 Authorization，還有登入回應裡回來的那些 token。拿到這個檔案的人，在那些值過期之前，常常可以直接用你的身分操作。據公開報導，2023 年 Okta 客服系統的資安事件，就是從客戶上傳到客服案件的 HAR 檔裡拿到了 session token——檔案只是做了它本來就會做的事。這頁會在你的瀏覽器裡打開最大 200 MiB 的 .har，列出找到的東西，再產生一份把那些值換掉的副本。不上傳，頁面背後也沒有伺服器。
請求端的 cookie（Cookie header 與 cookies 陣列）和回應端的 Set-Cookie，其中帶 HttpOnly 或 Secure 的會標成疑似 session cookie。Authorization 與 Proxy-Authorization：Bearer、Basic（Basic 是可以直接還原的帳號加密碼，不是雜湊）、Digest。網址裡的 user:pass@。已知的 token header，像 x-api-key、x-csrf-token、x-amz-security-token、x-goog-api-key。請求網址、重新導向、Location 與 Referer header 裡長得像祕密的參數——token、access_token、id_token、code、state、signature、X-Amz-Signature、password 這類，連 fragment 裡的 #access_token 也算。表單和 JSON 內文裡的密碼與 token，包括帶 access_token、refresh_token 的 OAuth 回應。檔案裡任何位置的 JWT，會顯示 alg、iss、sub 和到期時間——簽章不會驗證。私鑰（-----BEGIN … PRIVATE KEY-----）。回應內文裡疑似的個資：email、E.164 格式電話、通過 Luhn 檢查的卡號、檢查碼正確的台灣身分證字號。還有內部主機：localhost、127/8、10/8、172.16/12、192.168/16 和 file:// 網址，這些會把你的內網長什麼樣子告訴外人。
每一筆你保持勾選的項目，值都會換成 [REDACTED]，名稱留著，所以客服還是看得出這裡本來有一個 Cookie header 或 access_token 欄位。內部主機名稱換成 redacted.invalid，被改過的請求或回應，記錄的 header 與 body 大小會改成 -1（未知），因為原本的數字已經對不上修改後的內容。副本在提供下載之前會再掃一次，頁面會顯示清除前 N 筆、清除後 M 筆——只要是它會找的東西還留著，你一定看得到。個資會列出來但預設不勾：把回應裡的 email 換掉，很可能剛好把廠商需要看的那個 bug 藏起來，所以這個決定逐筆交給你。如果整個檔案連一個 cookie、一個 Authorization 都沒有，頁面會提醒你——Chrome DevTools 匯出 HAR 時可以選擇含不含敏感資料，這看起來就是不含的那種。
它只認得已知的形狀。你的 app 把 token 放在一個叫 x 的內文欄位裡，或用了這裡沒見過的格式，就可能漏掉。所以報告永遠不會說「這個檔案安全了」，它只說清掉了什麼、你留下了什麼。個資比對一律標「疑似」而且不完整，不能取代你自己在分享前把檔案看過一遍。清除後的請求沒辦法重放——這正是目的。以 base64 存的二進位回應（圖片、字型、下載檔）不會掃。反過來用也行：別人寄 HAR 給你，先丟進來看看對方交出了什麼，再決定要不要轉寄。
匯出來那份不建議直接給。HAR 把每個請求的 header 和 cookie 都錄下來了，所以登入狀態下匯出的檔案，一定帶著那個 session 靠的 cookie 或 token，拿到檔案的人在它過期之前常常可以直接用。先丟進這頁：它會列出所有認得的 cookie、Authorization、token、JWT、私鑰和內部主機，你再下載一份把這些值換掉的副本。這份副本不會被宣告「安全」——報告只告訴你清掉了什麼、你選擇留下什麼，最後一眼還是要你自己看。
不會。檔案用 File API 打開，在這個分頁裡解析，清除後的副本是瀏覽器從記憶體直接產生的下載。這頁背後沒有 API，檔案根本沒有地方可去——而這正是你最不想放到任何伺服器上的檔案：裡面有你還活著的 session。
你錄到的那些頁面，瀏覽器送出和收到的全部：每個請求的 Cookie header、每個回應的 Set-Cookie、Authorization 與 Proxy-Authorization、x-api-key 這類自訂 token header、網址和重新導向 Location header 裡的 token（OAuth 常常就是用 code、state，甚至 #access_token 這樣傳）、登入表單裡的密碼、JSON 裡的 token 回應，有時候回應內文裡還會有私鑰或個資。請求網址也會透露你內網有哪些主機——localhost、10.x、192.168.x、file:// 路徑——那是一張不該給別人的地圖。
可以。每一筆發現都是一個勾選框。除了疑似個資以外，所有項目一開始都是勾起來的；想留的就取消勾選，例如客服重現問題需要的公開 API key。值會換成 [REDACTED]，名稱留著，所以每個請求的結構還是讀得懂。副本下載前會再掃一次，清除前後的筆數並排給你看。
因為客服案件通常就是在談那些資料。如果 bug 是個人頁面顯示了錯的 email，HAR 裡 email 被換成 [REDACTED] 之後，工程師最需要看的那一個反而不見了。所以回應內文裡的個資——email、E.164 電話、通過 Luhn 的卡號、檢查碼正確的台灣身分證字號——會列成「疑似個資」，交給你決定勾不勾。這個偵測本來就不完整：它看到姓名或地址並不會認得。
JWT 是三段 base64：header、claims、簽章。這頁會解開前兩段，顯示演算法（alg）、簽發者（iss）、主體（sub）和到期時間，你就知道檔案裡那顆 token 是還活著的，還是幾週前就過期了。它不會驗證簽章——手上沒有金鑰可以驗——所以沒辦法告訴你伺服器會不會接受。到期時間還在未來的 JWT，一律當成拿到檔案的人就能用。
拿來讀，可以：網址、請求順序、狀態碼、時間、每個 header 和欄位的名稱、所有不敏感的內文，全部沒變。拿來重放請求，不行——憑證已經不在了，交出清除後的檔案就是為了這個。工程師要重現某個呼叫，應該用他自己的憑證，不是你的。
只表示這頁認得的那些形狀都不在裡面。如果整份 HAR 連一個 cookie、一個 Authorization 都沒有，頁面會提醒你這看起來像是匯出時就把敏感資料排除掉的版本，Chrome DevTools 做得到。放在冷門 header 裡的 token、欄位名稱出乎意料的密碼、藏在二進位回應裡的祕密，它都看不到。真的重要的檔案，分享前還是自己把內文看一遍。
找出準備貼上或送出的文字裡，藏著的零寬、bidi 與 tag 字元。
Word、Excel、PowerPoint 版：作者、追蹤修訂、檔案路徑一次看。
分享截圖前，先把畫面上的 token 和名字塗掉。
查 HAR 裡出現的 HTTP 狀態碼是什麼意思。