How do I check whether a tool is client-side?

Open DevTools (F12) → Network tab, enable "Preserve log," paste recognizable test data into the tool, and process it. If no request containing your test string fires, the tool is client-side. On Chrome you can also switch DevTools to "Offline" after page load — a true client-side tool keeps working.

Are client-side tools slower than server-side ones?

For typical developer tasks, they're faster — there's no upload, no queue, no download. Processing a 2 MB JSON file locally is near-instant, while a server round-trip adds latency at every step. The exception is heavy computation (large video transcodes, gigabyte-scale files), where a powerful server beats a browser tab.

Does toolz.dev collect anything at all?

Page-view analytics and anonymous per-tool usage counts (used for rate limits) — but never the content you process. Input, output, and uploaded files stay in your browser. This is verifiable with the Network tab check rather than something you have to take on faith.

Is pasting a JWT into an online decoder really risky?

Yes, more than most developers assume. Per RFC 7519, JWT payloads are encoded, not encrypted — anyone holding the token can read the claims, and if the token hasn't expired, it may be usable as a live credential. Pasting one into a server-side decoder transmits a possibly-valid session token to an unknown third party. Use a client-side decoder.

Does using client-side tools make me GDPR compliant?

No single tool choice makes you compliant. What client-side tools remove is one specific risk: personal data from your systems reaching an unvetted third-party processor (which would require an Article 28 data processing agreement you almost certainly don't have with a free tool site). Your own product's obligations are unaffected.

Can my employer see what I process in client-side tools?

Network monitoring sees which sites you visit, not what you type into a client-side tool — there's no request carrying your input to observe. Endpoint monitoring installed on the device itself (screen capture, keyloggers) sees everything regardless of tool architecture, so the honest answer is: not via the network, possibly via the endpoint.

What if there's no client-side alternative for my task?

Sanitize before pasting: replace credentials with placeholders (YOUR_API_KEY), swap real personal data for dummy values, strip hostnames and internal URLs. Then check the tool's privacy policy for logging and retention language, prefer open-source tools you can inspect, and treat "free, closed-source, server-side" as the highest-risk combination.

What is the difference between client-side and server-side tools?

Client-side tools ship code to your browser and run it there; server-side tools ship your data to a machine you don't control and run it there. Functionally the output can be identical — the difference is entirely about who ends up holding your input. With a server-side tool your data exists, however briefly, on someone else's disk, in their logs, and in their backups.

Are online JSON formatters and beautifiers safe to use?

It depends on the implementation, not the category. Formatting JSON is trivial to do in JavaScript, so a client-side formatter has no reason to transmit anything — and the Network tab check settles it in ten seconds. Be more careful than usual here, because the JSON developers paste into formatters is disproportionately API responses containing tokens, email addresses, and internal IDs.

כלים בצד הלקוח ופרטיות נתונים: לאן בעצם הולכת ההדבקה שלך

שנים של עושה תמיכה תוסף וורדפרס לימד אותי הרגל רע לקוח שולח לך שבור אפשרויות מסודרות כתם, אתה צריך לקרוא את זה עכשיו עכשיו, אז אתה מדביק אותו לתוך unserializer המקוון הראשון Google נותן לך.עשיתי את זה במשך זמן רב בלי לחשוב על זה - עד היום שהסתכלתי על מה I & #39;d רק מודבק.זה היה לקוח & #39;s wp_options יצוא. זה הכיל את סיסמת ה-SMTP שלהם, מפתח API של Mailchimp ומפתח רישיון. הכל פורסם זה עתה לשרת שלא ידעתי עליו דבר, המנוהל על ידי מישהו שיכולתי 't name, במדינה שיכולתי 't guess.

שום דבר רע לא קרה, למיטב ידיעתי. That's החלק המטריד - אין לי דרך לדעת. There's אין הודעה עבור " הדבק שלך נרשם." הנתונים ישבו ב- someone's יומני גישה או שזה עשה 't, ו-I' לעולם לא יגלה איזה.

התקרית הזו היא חלק גדול מהסיבה ש-Toolz.dev עובד כמו שהוא עובד. כל אחד מ-50 הכלים באתר מעבד את הקלט שלך בדפדפן שלך. לא " אנו מבטיחים שנמחק אותו לאחר עיבוד" - הוא אף פעם לא מועבר מלכתחילה. מדריך זה מסביר את ההבדל בין שתי הארכיטקטורות הללו, מדוע זה חשוב יותר למפתחים מאשר כמעט לכל אחד אחר, וכיצד לאמת כלי 's טוען את עצמך תוך כ-30 שניות. ומכיוון שבסופו של דבר הדבקתי את כתם הלקוח במקום בטוח, ה PHP Unserializer שהחליף את ההרגל הרע שלי.

TL;DR: כלים בצד השרת משדרים את הקלט שלך למישהו אחר 's מכונה, שם ניתן לרשום, לשמור, לפרוץ או לשתף אותו - ואתה יכול 't לאמת כל אחד מהם כלים בצד הלקוח שולחים לך את הקוד ומעבדים הכל באופן מקומי; אימות לוקח בדיקת כרטיסייה אחת של DevTools Network לכל דבר המכיל אישורים - JWTs, wp-config ערכים, מחרוזות חיבור, תגובות API - השתמש בכלים בצד הלקוח כמו פורמט JSON, מפענח JWT, פורמט SQL, ו מאמת יאמל. הכל על Toolz.dev פועל בדפדפן.

מה בעצם קורה כשאתה מדביק לכלי מקוון?

יש בדיוק שתי ארכיטקטורות, וכל כלי מקוון משתמש באחת מהן.

צד השרת: הקלט שלך עובר מהדפדפן שלך אל הכלי & #39;s שרת, מקבל מעובד שם, והתוצאה נעה אחורה. חמישה שלבים, והנתונים שלך קיימים על מישהו אחר & #39;s תשתית במהלך שלושה מהם.

Your browser → network → their server → network → your browser
   (input)     (transit)  (processing,    (transit)   (result)
                           logging?,
                           retention?)

צד הלקוח: הדפדפן שלך מוריד את הכלי's JavaScript פעם אחת, ואז הכל - קלט, עיבוד, פלט - קורה בכרטיסייה במחשב שלך הדבר היחיד שאי פעם חצה את הרשת היה הקוד.

Their server → your browser
   (code)       (input + processing + result, all local)

ההבחנה נשמעת אקדמית עד שאתה מפרט מה יכול לקרות לנתונים בשרת שאתה עושה ' t control. זה יכול לנחות ביומני גישה ויומני יישומים. זה יכול להילכד על ידי עוקבי שגיאות כמו Sentry, אשר תמונת מצב מבקשת הקשר כאשר משהו זורק. זה יכול להישמר בגיבויים הרבה אחרי המפעיל " נמחק" זה. זה יכול להיקרא על ידי כל עובד עם גישה ליומן. זה יכול להיסחף בפרצה. ועם כמה " כלי חינם" מפעילים, זה יכול להיות המוצר בפועל - מונטיזציה באמצעות ניתוח או נמכר כנתוני אימון.

אף אחד מאלה דורשים זדון תצורות רישום ברירת מחדל לבד יעשה את רוב זה המפעיל של אותו unserializer השתמשתי כנראה מעולם לא הסתכל על הלקוח שלי 's סיסמת SMTP.אבל "כנראה" הוא לא תנוחת אבטחה.

מדוע זו עסקה גדולה יותר עבור מפתחים מאשר עבור כל אחד אחר?

בגלל מה שאנחנו מדביקים משתמש ממוצע מדביק פסקה של טקסט לתוך מונה מילים מפתח מדביק:

תגובות API עם אסימונים חיים. You're איתור באגים באינטגרציה, אתה מעתיק את כל התגובה - כותרות כלולות - ומעצב אותה כדי לקרוא אותה. זֶה Authorization: Bearer ... הכותרת פשוט הלכה לכל מקום שהפורמט גר. GitGuardian's מצב הסודות התפשטות מחקר מצא כ-12.8 מיליון סודות שנחשפו בהתחייבויות ציבוריות של GitHub בשנת 2023 בלבד. אף אחד לא מפרסם מספרים מקבילים עבור כלים מקוונים, מכיוון שבניגוד ל-GitHub, מפעילי כלים ' יומנים aren't ניתנים לסריקה פומבית. זה ו#39; לא מרגיע - זה אומר שמשטח הדליפה אינו נראה.

JWTs. אסימון אינטרנט של JSON מקודד base64url, לא מוצפן - RFC 7519 מפורש לגבי זה. המטען של כל אסימון שאתה מדביק במפענח בצד השרת מוסר את המשתמש ' מזהה s, דואל, תפקידים ותפוגה. אם האסימון עדיין תקף, אתה ' ייתכן שמסרת אישור הפעלה. פענח אותם באופן מקומי עם מפענח JWT במקום.

SQL עם נתונים אמיתיים בתוכו. לשאילתה you're formatting יש א WHERE email = '[email protected]' סעיף בו, ושמות הטבלה משרטטים את כל הסכימה שלך. ה פורמט SQL שומר את זה בכרטיסייה שלך.

הגדר קבצים. wp-config.php ערכים, .env תוכן, מניפסטים של Kubernetes, database.yml- תצורה היא המקום שבו אישורים חיים. I' אימתתי קבצי YAML שהכילו כל סוד שהיה לאפליקציית Laravel שלי. That's משחה שאתה רוצה לעבור דרך צד הלקוח מאמת יאמל, לא טופס POST.

נתוני וורדפרס מסודרים. הנפילה האישית שלי, לפי המבוא. וורדפרס מאחסנת אפשרויות ומטא נתונים כמחרוזות בסידרה של PHP, וניפוי באגים בהם פירושו ביטול סדרה שלהם - ה PHP Unserializer עושה את זה בלי הלקוח שלך & #39;s נתונים עוזבים את המכונה שלך.

משחה רשלנית אחת מכל אחת מהקטגוריות הללו היא אירוע אבטחה שאף אחד לעולם לא יזהה, ידווח או ינקה.

כיצד אתה מוודא שכלי הוא למעשה צד הלקוח?

זה החלק שאני הכי אוהב בארכיטקטורה בצד הלקוח: אתה לא צריך לסמוך על אף אחד 's מדיניות הפרטיות. התביעה ניתנת לאימות מכנית.

פתח את דף הכלי 's.
פתח את DevTools (F12) → רשת כִּיבָה. בדוק "הזמן יומן."
הדבק כמה נתוני בדיקה ניתנים לזיהוי - MY-SECRET-TEST-12345 עובד - ולהפעיל את הכלי.
צפו ברשימת הבקשות.

אם הכלי הוא בצד הלקוח, אתה & #39; תראה את טעינת הדף הראשונית והנכסים הסטטיים, ולאחר מכן שום דבר כשאתה מעבד אם בקשה נדלקת כשאתה לוחץ על כפתור המר/פורמט/עיבוד, סנן את הבקשות ובדוק את המטענים עבור מחרוזת הבדיקה שלך. מצאתי את זה? צד השרת. בוצע - זה לקח חצי דקה, ועכשיו אתה יודע יותר על הכלי הזה ממה שמדיניות הפרטיות שלו הייתה אומרת לך אי פעם.

שתי הערות כנות על Toolz.dev, כי זה חותך לשני הכיוונים. ראשית, האתר אכן טוען ניתוח עבור ספירת צפיות בדף ועושה מעקב שֶׁז נעשה שימוש בכלי - למגבלות שימוש - אך מעולם לא מה אתה מכניס לתוכו.הפעל את בדיקת הרשת בעצמך; הקלט לעולם לא מופיע בשום בקשה. שנית, לצד הלקוח יש מגבלה אמיתית: הדפדפן שלך עושה את העבודה, אז המרת וידאו של 4 GB isn't קורה בכרטיסייה. עבור קטגוריית הכלים של מעצב/ממיר/מקודד, עם זאת, JavaScript המודרני הוא יותר ממהיר מספיק - בדרך כלל מהיר יותר מצד השרת, כי שם' אין העלאה הלוך ושוב.

צד שרת לעומת צד לקוח: ההשוואה הישרה

	כלים בצד השרת	כלים בצד הלקוח
איפה עיבוד קורה	Operator's שרת	הדפדפן שלך
נתונים מועברים?	כן, בכל פעם	לא - רק הכלי's קוד מוריד
ניתן לרשום/לשמור על ידי המפעיל	כן, לעתים קרובות כברירת מחדל	לא - מפעיל אף פעם לא מקבל את זה
נחשף בהפרה של הכלי	כן, אם נשמר	לא
ניתן לאימות על ידך	לא - אתה סומך על המדיניות	כן - כרטיסיית DevTools Network, ~30 שניות
דרוש הסכם מעבד GDPR	כן, אם נתונים אישיים (סעיף 28)	לא מתרחש עיבוד על ידי צד שלישי
עובד במצב לא מקוון לאחר הטעינה	לא	לעתים קרובות כן
מהירות עבור משימות dev טיפוסיות	העלה + תור + הורדה	מיידי - ללא רשת הלוך ושוב
חישוב כבד (וידאו, קבצים ענקיים)	מתאים יותר	מוגבל על ידי המכשיר שלך

I' אני מפתח, לא עורך דין, אז התייחס לזה כהקשר הנדסי ולא ייעוץ משפטי - אבל המתווה חשוב לכל מי שמטפל בנתוני המשתמשים של האיחוד האירופי.

תחת תקנה (EU) 2016/679 (GDPR), אם אתה לוקח נתונים אישיים - לקוח & #39;s תמיכה ייצוא, תגובת API עם רשומות משתמש - ולדחוף אותו דרך צד שלישי & #39;s שרת, כי צד שלישי הוא עיבוד נתונים אישיים בשמך סעיף 28 אומר כי דורש הסכם עיבוד נתונים שאל את עצמך כמה מעצבים מקוונים חינם מציעים DPA.מעולם לא ראיתי אחד.

כלים בצד הלקוח עוקפים את כל השאלה, לא באמצעות ניסוח משפטי חכם אלא באמצעות ארכיטקטורה: אין נתונים מגיעים לספק, ולכן אין עיבוד של צד שלישי לנייר. מזעור נתונים (סעיף 5 (1) (ג)) מסופק בצורה המילולית ביותר האפשרית - כמות הנתונים שלך שהספק אוסף היא אפס. אותו היגיון עוזר עם HIPAA (נתוני בריאות לעולם אינם מגיעים לשרת שאינו תואם), ביקורת SOC 2 (ללא מעבד משנה לא נבדק בנתיב הנתונים), ו-PCI DSS.

שיהיה ברור: שימוש בכלים בצד הלקוח עושה 't make המוצר שלך תואם GDPR. זה מסיר דליפה אחת ספציפית ונפוצה באופן מפתיע בזרימת העבודה שלך בפיתוח - זו שבה מפתח, שמנסה לעזור בכרטיס תמיכה, מדביק נתונים אישיים לאתר אקראי.

אילו משימות לעולם לא צריכות לגעת בשרת?

הניסוי האישי שלי, ממוין לפי כמה תזיק דליפה:

לעולם לא בצד השרת - מכיל או מרמז על אישורים:

עיצוב תגובות API ומטענים: פורמט JSON
אסימוני פענוח: מפענח JWT, ממיר Base64
עיצוב שאילתות: פורמט SQL
אימות תצורה: מאמת יאמל
איתור באגים בנתוני וורדפרס: PHP Unserializer
גיבוב והשוואת ערכים: מְחוּגָה
יצירת אישורים: מחולל סיסמא, מחולל UUID

העדיפו מאוד את צד הלקוח - קנייני אך לא סודי:

קוד פנימי או חוזים שונים: הבדל טקסט, JSON Diff
בדיקת regex מול קווי יומן ייצור: בודק רגקס
המרת חותמות זמן מתוך יומנים ואסימונים: ממיר חותמת זמן
דחיסת צילומי מסך פנימיים: מדחס תמונה

הימורים נמוכים, אבל צד הלקוח עדיין פשוט מהיר יותר:

ספירת מילים: מונה מילים
טקסט מציין מיקום: מחולל Lorem Ipsum
צבעים ושיפועים: בוחר צבעים, מחולל שיפוע

There' הוא הדרכה ארוכה יותר של ארגז הכלים המלא ב- מדריך כלי פרודוקטיביות למפתחים וה מדריך כלי קידוד.

אם אתה באמת צריך כלי בצד השרת - המרה כבדה ללא חלופה מקומית - חיטוי תחילה. החלף מפתחות אמיתיים עבור YOUR_API_KEY, מיילים אמיתיים עבור [email protected]. It's 60 שניות של חיפוש והחלפה שהופכים אירוע פוטנציאלי לאי-אירוע.

מדוע רוב הכלים המקוונים נמצאים בצד השרת בכל מקרה?

חלקית היסטוריה, חלקית תמריצים. בשנת 2010, הדפדפנים היו' עד לתפקיד - עיבוד כבד היה צריך לקרות בשרת. האילוץ הזה נעלם: מנועי JavaScript מודרניים ו-WebAssembly מטפלים בעיצוב, המרה, גיבוב ודחיסת תמונה במהירויות שאינן ניתנות להבדלה מממשקי API מקוריים ודפדפנים (קובץ, קנבס, קריפטו אינטרנט) מכסים את ה-I/O.

התמריצים הם הבעיה הדביקה יותר עיבוד בצד השרת מאפשר למפעיל לראות שימוש בפירוט, לאכוף מגבלות במדויק, לשמור על לוגיקה העיבוד קניינית, ובמקרים הגרועים ביותר - להתייחס לנתונים עצמם כהכנסה כלי שלעולם לא מקבל את הנתונים שלך יכול 't לייצר רווחים מהנתונים שלך, וזו בדיוק הסיבה שחלק מהמפעילים לא ' לא רוצים את הארכיטקטורה למרות שזה 's עכשיו קל מבחינה טכנית.

כשבניתי את הכלים עבור Toolz.dev, צד הלקוח היה למעשה ה פשוט יותר בחירה הנדסית, לא רק הפרטית יותר: אין שרתי עיבוד בקנה מידה, אין העלאות לאבטחה, אין מדיניות שמירה לכתיבה, וכל כלי עובד באופן זהה באפליקציית האינטרנט ובאפליקציית שולחן העבודה מכיוון שההיגיון הוא TypeScript רגיל לאגנוסטי לפלטפורמה. סיפור הפרטיות והסיפור ההנדסי מצביעים על אותו כיוון. It' נדיר כשזה קורה; קח את הניצחון.

שאלות נפוצות

מה עושה "עיבוד בצד הלקוח" בעצם מתכוון?

כל החישוב מתרחש בדפדפן שלך, ב-JavaScript (או WebAssembly), במכשיר שלך. התפקיד היחיד של server's הוא אספקת הכלי's קוד כאשר הדף נטען. הקלט שלך לעולם לא מופיע בשום בקשת רשת, אותה תוכל לאשר בכרטיסייה DevTools Network.

כיצד אוכל לבדוק אם כלי הוא צד הלקוח?

פתח את DevTools (F12) → לשונית רשת, הפעל " שמור יומן," הדבק נתוני בדיקה ניתנים לזיהוי בכלי, ועבד אותם. אם אין בקשה המכילה את מחרוזת הבדיקה שלך יורה, הכלי נמצא בצד הלקוח. ב-Chrome אתה יכול גם להעביר את DevTools ל-"Offline" לאחר טעינת העמוד - כלי אמיתי בצד הלקוח ממשיך לעבוד.

האם כלים בצד הלקוח איטיים יותר מאלה בצד השרת?

עבור משימות מפתח טיפוסיות, הם're מהר יותר - there's אין העלאה, אין תור, אין הורדה עיבוד קובץ JSON של 2 מגה-בייט באופן מקומי הוא כמעט מיידי, בעוד ששרת הלוך ושוב מוסיף חביון בכל שלב. היוצא מן הכלל הוא חישוב כבד (המרת וידאו גדולים, קבצים בקנה מידה גיגה-בייט), שבו שרת רב עוצמה מנצח לשונית דפדפן.

האם Toolz.dev לאסוף משהו בכלל?

ניתוח תצוגת עמוד וספירת שימוש אנונימית לכל כלי (המשמש למגבלות קצב) - אך לעולם לא התוכן שאתה מעבד. קלט, פלט וקבצים שהועלו נשארים בדפדפן שלך. זה ניתן לאימות באמצעות בדיקת הכרטיסייה רשת ולא משהו שאתה צריך לקחת על עצמך אמונה.

האם הדבקת JWT במפענח מקוון באמת מסוכנת?

כן, יותר ממה שרוב המפתחים מניחים. לפי RFC 7519, מטענים של JWT מקודדים, לא מוצפנים - כל מי שמחזיק באסימון יכול לקרוא את הטענות, ואם האסימון has ' t פג, זה עשוי להיות שמיש כאישור חי. הדבקת אחד במפענח בצד השרת משדרת אסימון הפעלה חוקי אולי לצד שלישי לא ידוע. השתמש במפענח בצד הלקוח.

אין בחירה אחת של כלי גורם לך להיות תואם מה כלים בצד הלקוח להסיר הוא סיכון אחד ספציפי: נתונים אישיים מהמערכות שלך להגיע למעבד צד שלישי לא נבדק (אשר ידרוש הסכם עיבוד נתונים סעיף 28 אתה כמעט בוודאות don't יש עם אתר כלי חינם). המוצר שלך & #39;s התחייבויות אינן מושפעות.

האם המעסיק שלי יכול לראות מה אני מעבד בכלים בצד הלקוח?

ניטור רשת רואה באילו אתרים אתה מבקר, לא מה אתה מקליד בכלי בצד הלקוח - שם' אין בקשה נושאת את הקלט שלך לצפייה. ניטור נקודות קצה המותקן במכשיר עצמו (לכידת מסך, keyloggers) רואה הכל ללא קשר לארכיטקטורת הכלים, כך שהתשובה הכנה היא: לא דרך הרשת, אולי דרך נקודת הקצה.

מה אם אין ' אין חלופה בצד הלקוח למשימה שלי?

לחטא לפני ההדבקה: החלף אישורים במצייני מיקום (YOUR_API_KEY), החלף נתונים אישיים אמיתיים עבור ערכי דמה, שמות מארחים של רצועות וכתובות URL פנימיות. לאחר מכן בדוק את הכלי 's מדיניות הפרטיות עבור שפת רישום ושימור, העדיף כלי קוד פתוח שתוכל לבדוק ולטפל ב-"חינם, קוד סגור, בצד השרת" כשילוב בסיכון הגבוה ביותר.

מה ההבדל בין כלים בצד הלקוח לצד השרת?

כלים בצד הלקוח שולחים קוד לדפדפן שלך ומריצים אותו שם; כלים בצד השרת שולחים את הנתונים שלך למכונה שאתה עושה ' לא שולט ומפעיל אותם שם. מבחינה פונקציונלית הפלט יכול להיות זהה - ההבדל הוא לחלוטין לגבי מי בסופו של דבר מחזיק את הקלט שלך. עם כלי בצד השרת הנתונים שלך קיימים, בקצרה ככל שתהיה, בדיסק של מישהו אחר 's, ביומנים שלהם ובגיבויים שלהם.

האם פורמטים ומייפים מקוונים של JSON בטוחים לשימוש?

זה תלוי ביישום, לא בקטגוריה עיצוב JSON הוא טריוויאלי לביצוע ב-JavaScript, כך שלפורמט בצד הלקוח אין סיבה לשדר דבר - ובדיקת הכרטיסייה רשת מסדרת אותו תוך עשר שניות היזהר יותר מהרגיל כאן, מכיוון שמפתחי JSON הדבק לתוך פורמטים הוא תגובות API באופן לא פרופורציונלי המכילות אסימונים, כתובות דואל ומזהים פנימיים.

Frequently Asked Questions

All computation happens in your browser, in JavaScript (or WebAssembly), on your device. The server's only role is delivering the tool's code when the page loads. Your input never appears in any network request, which you can confirm in the DevTools Network tab.