Open Badges 平台比較:所有主要工具並列評比
Open Badge v2.0 平台的終極並列比較——功能、價格方案、API 存取權限與標準相容性,全部整理在一張表格中。
如果你搜尋過「open badges platform comparison」,大概會找到兩種頁面:一種是廠商自家寫的「我們 vs. 競爭對手」文章,另一種則是內容單薄的整理清單,從來沒說清楚誰的收費是多少。這兩種都無法回答方案負責人在評估 Open Badge 軟體時真正想知道的問題:哪個平台適合我的發行量、我的預算與我的領證對象,哪些又是大材小用或功能不足。
這篇文章是中立、涵蓋全市場的版本。以下每個平台都會發行 Open Badge v2.0 憑證,所以真正重要的差異在於計價模式、你拿到的是視覺化設計工具還是範本選擇器、API 是否內建還是要透過業務電話才能取得,以及發行後的驗證方式。我們會持續更新這張表格,並為文中提到的每個平台附上更深入的專門比較文章。
完整比較表(2026 年)
| 平台 | Open Badge v2.0 | 免費方案 | 入門付費方案 | 視覺化設計工具 | 所有方案皆含 API | 公開驗證頁面 |
|---|---|---|---|---|---|---|
| Badges Ninja | 有 | $0 — 每年 1,200 張憑證,無每月上限 | Starter,$9/月(每年 12,000 張) | 有——80 種以上範本、形狀與圖示 | 有,免費方案也包含 | 有,所有方案皆含 |
| Credly | 有 | 無 | Enterprise,需洽業務 | 有限 | 僅限 Enterprise 方案 | 有 |
| Badgr | 有 | 每月 100 個徽章,不可結轉 | 約 $50/月 | 基本款 | 僅限付費方案 | 有 |
| Accredible | 有 | 總共 10 個徽章(試用) | $99/月 | 有,限付費方案 | 僅限付費方案 | 有 |
| Sertifier | 有 | 總共 10 個徽章(試用) | $59/月 | 有 | 僅限付費方案 | 有 |
| Open Badge Factory | 有 | 業務主導,未公開免費方案 | 需洽業務 | 基本款 | 僅限 Enterprise 方案 | 有 |
| Certifier | 有 | $0 — 每年 250 張憑證 | 約 $67-79/月(每年上限 3,000 張) | 有 | 依方案分級開放 | 有 |
| VirtualBadge | 有 | 業務主導,無免費方案 | 客製化,每年數千張 | 有 | 僅限 Enterprise | 有 |
| POK | 有,並提供區塊鏈錨定 | 無,採企業合約制 | 據傳每年 €10,000-€50,000 以上 | 有限 | 僅限 Enterprise | 有 |
| BCdiploma | 有,並提供區塊鏈公證 | 無,採企業合約制 | 據傳每年 $50,000-$200,000 以上 | 有限 | 僅限 Enterprise | 有 |
| Hyperstack | 有 | 業務主導,未公開免費方案 | 客製化,面向機構 | 有 | 僅限 Enterprise | 有 |
若廠商未公開價格,以上數字是根據公開報價與買家回報整理出的估計範圍,並非官方定價——實際條款請直接向廠商確認。
這個市場的三種樣貌
把這 11 個平台依銷售方式與目標客群分類,就會落入三個明顯不同的群組;而「該選哪個平台」這類問題之所以讓人困惑,多半是因為拿不同群組的平台互相比較,而不是在同一群組內比較。
適合每年發行不到 10,000 張憑證的自助式平台
Badges Ninja、Badgr、Sertifier 和 Certifier 都可以用電子郵件註冊,當天就能發出第一張憑證,不需要業務電話。在這個群組裡,真正的差異在於免費方案的額度有多寬鬆、API 與批次 CSV 上傳是內建還是分級鎖定,以及付費方案的擴充方式。
Badges Ninja 的免費方案提供每年 1,200 張憑證,以彈性的年度額度計算,沒有每月上限,而且從第一天起就包含視覺化設計工具、API 與批次 CSV 上傳。Badgr 的免費方案則是每月重置 100 個徽章、不可結轉,適合發行量穩定的每月節奏,但遇到畢業典禮或以梯次為單位、發行量會暴增的方案就會不夠用。Sertifier 和 Certifier 都把免費方案定位為試用(分別是 10 張與 250 張憑證)而非正式量產方案,API 存取權通常要升級到付費方案才會開放。
企業導向、業務主導的平台
Credly、Accredible、VirtualBadge 和 Hyperstack 都是為擁有採購流程的大型組織打造的,計價方式也反映這一點——它們都不公開自助式價目表,想知道實際價格通常得先經過一次業務對談。作為交換,它們提供自助式工具沒有的東西:與現有 HR/LMS 系統的深度整合、白標品牌、專屬客戶經理,以及專為向管理層匯報而設計的分析儀表板。如果你的方案透過現有的企業軟體系統每年發行數萬張憑證,這些額外成本能換來真正的能力;但如果你只是兩人小組的訓練團隊、每季發行幾百個徽章,這樣的平台規模就顯得大材小用。
這四家平台彼此也不能互相替代。Credly 的優勢在於面向雇主的網路效應——招募人員與用人主管本來就會瀏覽這個平台,對於和聘用決策掛鉤的證書來說格外重要。Accredible 更著重分析與白標呈現,適合需要向董事會匯報參與度數字的方案。VirtualBadge 和 Hyperstack 則更靠代管服務而非網路觸及率取勝:你可以預期會有專屬的導入流程與持續的客戶支援,而不是自己設定的自助式儀表板。
歐盟機構型與區塊鏈公證平台
Open Badge Factory、POK 和 BCdiploma 服務的是更狹窄、特定的需求:歐盟資料落地、大學等級的合規框架,或是在區塊鏈上進行加密公證,而不只是託管式驗證頁面。Open Badge Factory 在這方面資歷最深,擁有芬蘭代管的基礎架構,並有長達十年被歐盟大學採用的紀錄。POK 額外提供 ELM(European Learning Model)相容性,以及針對大學成績單設計的區塊鏈錨定功能。BCdiploma 則走得更遠,將學位證書上鏈公證,背後還有專利組合支撐這套做法。如果你的機構明確要求把區塊鏈公證或歐盟資料落地當作合規檢核項目,這三個平台都非常合適;如果沒有這類需求,選擇它們就是昂貴的大材小用。
標準與驗證:「Open Badge v2.0」實際保證了什麼
這張表格裡的每個平台發行的都是 Open Badge v2.0 憑證,也就是說底層的斷言(assertion)都是符合固定 schema 的 JSON-LD:一個 issuer、一個 BadgeClass,以及一則把領證人與該 BadgeClass 連結起來、附帶發行日期與驗證方法的 assertion。正是這項標準,讓一個平台發出的徽章能被理解該規格的工具辨識,也是為什麼「符合 Open Badge 標準」只是基本門檻,本身並不足以構成差異化。
真正有差異的是驗證如何被呈現出來。包括 Badges Ninja 在內的多數平台,都提供不需註冊即可存取的公開驗證頁面——招募人員或用人主管只要點一個連結,就能確認憑證是真的。在 Badges Ninja 上,每張獎項的驗證頁面都有可預測的網址,同一則 assertion 也能以原始的 Open Badge v2.0 JSON-LD 格式取得,方便程式化檢查:
curl https://api.badges.ninja/certify-badge/award/your-award-id
這個端點不需要 API 金鑰——驗證機制刻意設計成公開的。對應的人類可讀版本是 https://badges.ninja/awards/<award-id>,也就是領證人會分享在 LinkedIn 或電子郵件簽名檔裡的連結。
在選擇平台之前,還有一個值得了解的標準細節:Open Badge v3.0 是一套更新、以 W3C Verifiable Credentials 為基礎的規格,但整個生態系尚未轉移過去——LinkedIn 的「加入個人檔案」流程、多數徽章錢包,以及這張表格裡的每個平台,目前都是基於 v2.0 打造的。除非有特定的驗證方要求 v3,否則 v2.0 在 2026 年仍是更保險的選擇;完整的遷移時程請參閱 Open Badge v2 vs v3。
批次發行:CSV 上傳 vs. 手動輸入
如果你要發行的對象是一整個梯次而不是一次一位領證人,就不要只看行銷文案,要實際確認批次發行是否包含在你要付費的方案裡,以及瀏覽器連線中斷後是否還能繼續。在自助式平台上,批次 CSV 上傳通常都有提供,但有時會保留給付費方案(Sertifier 和 Certifier 都把它鎖在免費/試用方案之上)。Badges Ninja 在所有方案(包括免費方案)都提供支援暫停與繼續的 CSV 批次上傳——你可以在批次進行到一半時關閉分頁,之後再從中斷處繼續,因為工作狀態是存在伺服器端,而不是瀏覽器裡。在企業級平台上,批次發行通常也有提供,但往往要透過客戶經理或 LMS 整合來執行,而不是自助式上傳畫面,這雖然會拉長作業時間,卻也為龐大、雜亂的機構資料增加了驗證環節。
API 存取權:全面開放,還是依方案分級鎖定
如果你打算從 LMS、CRM 或課程完成的 webhook 自動發行憑證,而不是透過儀表板一次發一張,API 存取權就是最關鍵的欄位——也是多數比較文章輕描淡寫帶過的一項。仔細看上面的表格就會發現一個規律:在多數平台上,API 存取權是付費方案或企業方案才有的功能,並不是免費帳號就能測試的東西。
Badges Ninja 在所有方案(包括免費方案)都提供完整的 API 存取權——Free 方案可建立 1 支 API 金鑰,Starter 可建立 5 支,Pro 可建立 20 支。金鑰都是從儀表板建立與撤銷,建立當下會完整顯示一次,之後就會遮蔽處理。

從你自己的程式碼發行憑證,只需要一次通過驗證的請求:
const res = await fetch("https://api.badges.ninja/awards", {
method: "POST",
headers: { "X-Api-Key": API_KEY, "Content-Type": "application/json" },
body: JSON.stringify({
badgeId: "your-badge-id",
recipient: { name: "Jane Smith", email: "jane@example.com" },
issuedOn: Date.now(),
}),
});
const { awardId } = await res.json();
這個請求會回傳一個 awardId,驗證頁面則是 https://badges.ninja/awards/<awardId>。能在 $0 帳號上實際跑出這個請求、而不用先做任何承諾,跟簽約之後才向業務代表索取 API 文件相比,是截然不同的評估體驗。
遷移:換平台時實際會改變什麼
因為這裡的每個平台輸出的都是 Open Badge v2.0,從一個平台換到另一個平台並不是從零重建,而是三個具體步驟。第一,你要在新平台的設計工具裡重新製作徽章樣式(如果平台支援自訂圖片,也可以直接上傳既有的美術素材)。第二,你要批次匯入領證人清單,通常透過 CSV,讓過去的獎項紀錄也存在於新系統中。第三,把原本觸發發行的機制——LMS 完成課程的 hook、CRM 階段變更,或儀表板上的手動操作——改指向新平台的流程或 API,而不是舊平台。
你在舊平台上已經發行的憑證,無論分享到哪裡都會繼續有效;換平台不會回溯性地破壞某人去年下載的 PDF,或是他們貼在 LinkedIn 上的連結。往後改變的只是新獎項存放的位置,以及你指向大家的驗證網址。如果方案有大量自訂品牌或深度 LMS 整合(也就是上面提到的企業級平台),要抓比較多的遷移時間;如果只是自助式工具上單純的徽章與證書方案,需要的時間就少得多。
如何選擇
把你的情況對應到一個群組,而不是單一廠商:
- 每年不到 10,000 張憑證、注重預算、想先試用 API 再決定 —— 從 Badges Ninja 的免費方案開始;如果你的發行量是穩定、可預測的每月數字、沒有季節性暴增,也可以考慮 Badgr。
- 需要與現有企業 HR 或 LMS 系統深度整合,而且反正都要走採購流程 —— Credly 或 Accredible 正是為這種情境打造的;請預期會有業務對談,以及五位數以上的年約金額。
- 合規要求明確需要歐盟資料落地或區塊鏈公證 —— 依機構份量與價格大致排序,可考慮 Open Badge Factory、POK 或 BCdiploma。
- 想要頂級服務式導入、內部又沒有人力自助操作 —— VirtualBadge 或 Hyperstack 會用自助式的速度換取代管式的建置服務。
如果想針對上面任一競爭對手做更深入的一對一比較——更細緻的價格拆解、逐項功能表格,以及遷移細節——請參考該平台所在列連結的專門比較文章。如果你還在篩選,這裡有兩個不錯的下一步:如果價格是決定因素,可以看 2026 年最便宜的 Open Badges 平台;如果你是依整體價值排名,可以看 2026 年最佳 Open Badges 平台。
準備好發行你的第一張可驗證憑證了嗎? 免費開始使用 badges.ninja —— 視覺化設計工具、公開驗證頁面、PDF 證書、Open Badge v2.0 輸出格式,不需要信用卡。
本文章是如何完成的
本部落格的部分文章是在 AI 助理協助下起草,並在發布前由 Badges Ninja 團隊審閱、查證與編輯。所有程式碼範例與價格皆已對照正式產品驗證。如需了解我們的編輯與 AI 流程,請參閱我們的 編輯流程頁面 .

關於作者
Nacho Coll
Founder & Engineer at Badges Ninja
Nacho founded Badges Ninja to make issuing verifiable digital credentials as simple as a single API call — Open Badge v2.0 badges and certificates, minted, hosted, and verifiable without standing up your own issuer infrastructure. Writes about the Open Badges spec, credential verification, and running a credentialing platform serverless on AWS, from the operator side of the wire.


