# Source Viewer — Tipps & Tricks

> Kniffe für den Source Viewer: was der Proxy sieht, warum private URLs nicht gehen, manuelle Sprachwahl, Beautify-Grenzen und Tool-Kombinationen.

Source: https://www.jpkc.com/db/tools/source/tips/

Zurück zur Übersicht: [Source Viewer](https://www.jpkc.com/db/tools/source/) · Tool live öffnen: [www.jpkc.com/tools/source/](https://www.jpkc.com/tools/source/)

Das [Manual](https://www.jpkc.com/db/tools/source/manual/) erklärt jede Funktion, die [Beispiele](https://www.jpkc.com/db/tools/source/examples/) zeigen die Abläufe. Hier geht es um das, was beides voraussetzt, aber selten dabeisteht: wo die Stolperfallen liegen, was der Proxy wirklich sieht und wie der Source Viewer mit anderen Tools zusammenspielt. Die Oberfläche ist auf Englisch — die echten Button- und Menü-Namen stehen deshalb im Original.

## Was der Proxy sieht — und was nicht

- **Geladen wird vom JPKCom-Server, nicht von deinem Browser.** Beim URL-Laden (Load, SEO, Analyze connection) holt ein serverseitiger Proxy die Seite. Die Zielseite sieht deshalb einen Request vom JPKCom-Server mit dessen User-Agent — **nicht deine IP-Adresse**. Das ist gut für die Privatsphäre, heißt aber auch: keine personalisierte, eingeloggte oder cookie-abhängige Sicht.
- **Nur das ausgelieferte Roh-HTML, kein gerendertes DOM.** Was eine Seite erst per JavaScript im Browser nachbaut — Inhalte, Meta-Daten, ganze SPA-Oberflächen — taucht im geladenen Quelltext nicht auf. Eine client-gerenderte App liefert oft nur ein fast leeres Grundgerüst. Das ist kein Fehler des Tools, sondern derselbe Grund, aus dem auch Crawler solche Seiten schlecht erfassen.
- **Private und interne URLs gehen nicht.** Aus SSRF-Schutz blockiert der Proxy private, lokale und interne IP-Adressen; erlaubt sind nur öffentliche **HTTP/HTTPS**-Adressen. Eine lokale Dev-Instanz, `localhost` oder eine Intranet-Seite kannst du nicht laden — entweder über eine öffentliche Staging-Domain bereitstellen oder den **Expert Mode** mit lokalem Proxy nutzen.
- **Große Seiten werden abgeschnitten, schnelles Klicken gebremst.** Es gilt ein Größenlimit von **rund 950 KB** und ein **15-Sekunden**-Timeout; die URL-Buttons teilen sich eine Drossel von **etwa einer Anfrage pro Sekunde** (sonst der Hinweis „Please wait …"). Bei sehr großen Dateien ist der geladene Quelltext also evtl. unvollständig.

## Die Sprachwahl ist manuell — denk daran

- **Es gibt keine Auto-Erkennung aus dem Inhalt.** Du wählst den Sprachmodus aktiv. Steht das Highlighting „falsch", liegt es fast immer an der noch nicht umgestellten Sprache.
- **Nach jedem URL-Load steht die Sprache auf HTML.** Egal ob du eine `.css`, `.js`, `.json` oder `.yml` geladen hast — der Editor nimmt erstmal HTML an. Stell danach von Hand auf die richtige Sprache um, sonst sehen z. B. CSS-Regeln aus wie unstrukturierter Text.
- **Sprache und Inhalt werden gespeichert.** Beides wandert in den lokalen Browser-Speicher und ist beim nächsten Besuch wieder da — praktisch, aber bedenke: Auf einem geteilten Rechner liegt dein letzter Stand sichtbar im Editor. Mit **Clear** räumst du auf.

## Beautify und Konvertierung richtig einsetzen

- **Beautify ist sprachabhängig.** Es laufen nur die **CSS-**, **HTML-** oder **JavaScript**-Routinen. Für eine andere Sprache passiert wenig Sinnvolles — wähl vorher den passenden Modus. Für minifizierten/verschleierten JS-Code greifen die mitgelieferten Unpacker, sodass auch gepackter Code wieder lesbar wird.
- **HTML → Markdown erzeugt Frontmatter.** Der Konverter zieht aus dem `<head>` ein YAML-Frontmatter (Titel, Description, OG, Twitter …) und stellt es voran. Willst du nur den Fließtext ohne Frontmatter, nimm den **Plain-Text**-Button statt des Markdown-Buttons.
- **Preview gibt es nur für Text und Markdown.** Bei allen anderen Sprachen ist der Vorschau-Button deaktiviert — stell also erst auf **Markdown** um, dann rendert die Vollbild-Vorschau (mit gehighlighteten Code-Blöcken und Frontmatter als `yaml`-Block).

## Keine KI im Tool — aber KI-freundlich

Der Source Viewer nutzt selbst **keine** KI: kein Modell, keine automatische Erkennung, keine Generierung. Die HTML-zu-Markdown-Funktion ist lediglich **KI-freundlich**, weil Markdown rauschärmer ist als HTML und sich gut als kompakte Quelle für ein Sprachmodell eignet. Erwarte also keine „intelligente" Sprach- oder Inhaltserkennung — alles ist deterministisch und von dir gesteuert.

## Mit anderen JPKCom-Tools kombinieren

Der Source Viewer ist ein guter Allrounder — für scharf umrissene Aufgaben gibt es spezialisiertere Tools:

- **[SEO & GEO Analyzer](https://www.jpkc.com/db/tools/seo/)** — wenn du statt eines kompakten Markdown-Berichts die vollständige, bewertete Analyse einer URL willst (zwei Scores, Tabs, SSL, Redirects, Structured Data). Nutzt denselben Proxy und denselben ACE-Editor im *Source Code*-Tab.
- **[Beautify](https://www.jpkc.com/db/tools/beautify/)** — der dedizierte Formatierer und Deobfuskator für JavaScript, CSS und HTML.
- **[Compiler](https://www.jpkc.com/db/tools/compiler/)** — SASS/SCSS kompilieren sowie HTML/JS/CSS minifizieren und verschönern, wenn der Editor-Beautify nicht reicht.
- **[Playground](https://www.jpkc.com/db/tools/playground/)** — wenn du HTML/CSS/JavaScript nicht nur ansehen, sondern live ausführen willst.
- **[Markdown Editor](https://www.jpkc.com/db/tools/md/)** — um das per HTML-zu-Markdown gewonnene Ergebnis komfortabel weiterzuschreiben.

---

Noch mehr Kontext: die [Übersicht](https://www.jpkc.com/db/tools/source/) zum großen Bild, das [Manual](https://www.jpkc.com/db/tools/source/manual/) für jede Funktion und die [Beispiele](https://www.jpkc.com/db/tools/source/examples/) für die Schritt-für-Schritt-Abläufe. Ausprobieren kannst du alles direkt im [Tool](https://www.jpkc.com/tools/source/).

