> JPG | encode | data-uri <
// JPG-/JPEG-Fotos zu Base64-Strings und Daten-URIs kodieren — EXIF, DCT-Koeffizienten und Qualität bleiben erhalten
JPG / JPEG hier ablegen oder klicken zum Auswählen
Klicken zum Durchsuchen von JPG-/JPEG-Dateien
Bit-identisch
Ihr JPEG wird nie neu komprimiert. DCT-Koeffizienten, Quantisierungstabellen und EXIF-Metadaten überstehen den Round-Trip unverändert.
Lokale Verarbeitung
Fotos werden im Browser mit FileReader + btoa() kodiert. Kein Upload, kein Server, keine Analytics auf Ihren Bild-Bytes.
Sofort einfügbar
Kopieren Sie eine standardkonforme data:image/jpeg;base64,…-URI direkt in HTML, CSS, E-Mails oder JSON-API-Payloads.
// FAQ — JPG ZU BASE64
F: Was ist JPG-zu-Base64-Kodierung?
A: Sie schreibt die binären Bytes einer .jpg-/.jpeg-Datei als ASCII-sicheren String unter Verwendung des Base64-Alphabets (RFC 4648) um. Der resultierende Text kann in HTML, CSS, E-Mails, JSON-Bodys oder jeden anderen reinen Textkanal eingebettet werden, ohne dass eine separate Datei nötig ist. Entscheidend: Das zugrunde liegende JPEG wird nicht neu kodiert — jeder DCT-Koeffizient, jede Quantisierungstabelle, jede Huffman-Tabelle und jeder EXIF-/IPTC-/XMP-Metadatenmarker bleibt erhalten.
F: Wie kodiere ich ein JPG zu Base64?
A: Ziehen Sie eine .jpg- oder .jpeg-Datei in den Upload-Bereich (oder klicken Sie zum Durchsuchen). Das Tool öffnet sie mit FileReader.readAsDataURL(), was eine direkt einfügbare data:image/jpeg;base64,/9j/4AAQSkZ…-URI erzeugt. Wählen Sie Daten-URI zur direkten Einbettung in <img> oder Nur Base64-Nutzdaten, wenn Ihre API die rohen Nutzdaten ohne das Präfix data:image/jpeg;base64, erwartet.
F: Verschlechtert die Kodierung eines JPG zu Base64 die Bildqualität?
A: Nein. Base64 ist eine reversible Binär-zu-Text-Transformation — keine Neukodierung. Die ursprüngliche Kompression des JPEGs (welche Qualitätsstufe, welcher Subsampling-Modus und welche Huffman-Tabellen auch immer verwendet wurden) bleibt Byte für Byte erhalten. Wenn Sie das Base64 zurück in eine Datei dekodieren, stimmt sein SHA-256-Hash mit dem Original überein. Der einzige Qualitätsverlust, der ein JPEG je betreffen konnte, geschah beim ersten Speichern aus einem Editor heraus; Base64 fügt keinen weiteren hinzu.
F: Warum beginnt jeder JPG-Base64-String mit <code>/9j/</code>?
A: Die ersten beiden Bytes jedes JPEG sind der Start-Of-Image-Marker FF D8, gefolgt von einem Anwendungs-Marker wie FF E0 (JFIF) oder FF E1 (EXIF). Wenn Sie die ersten 3 Bytes FF D8 FF in Base64 kodieren, erhalten Sie immer /9j/. Daher ist jeder String, der mit /9j/4AAQ (JFIF) oder /9j/2wC (viele Smartphone-Kameras) beginnt, zuverlässig ein JPEG — eine nützliche Plausibilitätsprüfung beim Debuggen.
F: Wie viel größer wird ein JPG nach der Base64-Kodierung?
A: Base64 fügt etwa 33 % Overhead hinzu: size_base64 = 4 × ⌈size_bytes / 3⌉. Ein 250-KB-Foto wird zu ~340 KB Text. Da JPEGs bereits komprimiert sind, bringt gzip/Brotli auf den Base64-String nur etwa 10 % zurück. Halten Sie bei Inline-Bildern die Quelle unter ~5 KB (≈ 6,8 KB kodiert), sonst blähen Sie Ihr HTML/CSS auf und beeinträchtigen die First-Paint-Performance.
F: Wie bette ich ein JPG als Base64 in HTML ein?
A: Fügen Sie die vollständige Daten-URI in das src-Attribut ein: <img src="data:image/jpeg;base64,/9j/4AAQSkZ…" alt="cover">
Es wird keine HTTP-Anfrage gestellt — der Browser dekodiert das Base64 und zeigt das Foto sofort an. Deshalb sind eingebettete JPEG-Thumbnails in Hero-Bereichen above-the-fold, E-Mail-Signaturen und HTML-Berichten als Einzeldatei beliebt.
F: Wie kodiere ich JPG zu Base64 in JavaScript, Node, Python, PHP, Go?
A:
JavaScript (Browser): new FileReader() + .readAsDataURL(jpgFile) → das result ist die Daten-URI
Node.js: fs.readFileSync('photo.jpg').toString('base64')
Python: base64.b64encode(open('photo.jpg','rb').read()).decode()
PHP: base64_encode(file_get_contents('photo.jpg'))
Go: base64.StdEncoding.EncodeToString(jpgBytes)
Ruby: Base64.strict_encode64(File.read('photo.jpg'))
Bash: base64 -w0 photo.jpg (GNU) oder base64 -i photo.jpg -o out.txt (macOS)
F: Bleiben meine EXIF-Daten erhalten, wenn ich ein JPG in Base64 kodiere?
A: Ja, standardmäßig. Das EXIF-Segment (Kameramodell, Datum/Uhrzeit, GPS-Koordinaten, Objektiv, Belichtung, Weißabgleich, Ausrichtung) liegt als APP1-Marker innerhalb des JPEGs. Da Base64 eine bitgenaue Transformation ist, überstehen die Marker sie intakt — beim Zurückdekodieren ist das EXIF genau so wie vorher. Wenn Privatsphäre wichtig ist (GPS-Koordinaten, Seriennummern), entfernen Sie EXIF vor der Kodierung mit einem Tool wie exiftool -all= oder einem Canvas-Reexport im Browser, denn Base64 selbst entfernt es nicht für Sie.
F: Wann sollte ich JPG → Base64 statt einer JPG-Einzeldatei verwenden?
A: Verwenden Sie Base64-JPEG-Daten-URIs, wenn:
• das Bild klein ist (< 5 KB) und kritisch für den First Paint
• Sie ein Foto innerhalb eines JSON-API-Bodys, einer GraphQL-Mutation oder eines WebSocket-Frames senden
• Sie eine eigenständige HTML-E-Mail, einen Report oder einen PDF-Export erstellen, die nicht auf externe CDN-URLs angewiesen sein dürfen
• Sie ein Foto in eine TEXT-Datenbankspalte serialisieren (wenn Sie kein BLOB verwenden können)
Bevorzugen Sie eine normale .jpg-URL, wenn das Bild groß ist, auf vielen Seiten wiederverwendet wird oder eigene Langzeit-Caching-Header benötigt.
F: JPG vs. JPEG — sind das unterschiedliche Formate?
A: Nein. .jpg und .jpeg sind lediglich unterschiedliche Dateiendungen für dasselbe Format (Joint Photographic Experts Group). Frühere Windows-8.3-Dateinamenbegrenzungen erzwangen dreibuchstabige Endungen, weshalb sich .jpg durchsetzte. Moderne Systeme akzeptieren beide. Der MIME-Typ ist immer image/jpeg, und das Base64-Daten-URI-Präfix lautet immer data:image/jpeg;base64, — unser Tool behandelt beide Endungen identisch.
F: Ist die Base64-Kodierung eine Form der Bildkompression?
A: Nein — es ist das Gegenteil. Das JPEG selbst ist bereits mit DCT + Huffman-Codierung komprimiert (erreicht eine 10–20-fache Reduzierung gegenüber den Rohpixeldaten). Base64 macht die Datei dann wieder ~33 % größer im Austausch gegen ASCII-Sicherheit. Sie sollten Base64 trotzdem nutzen, weil manche Kanäle (HTML-Attribute, JSON-Strings, E-Mails, URLs) keine rohen Binärdaten transportieren können. Erwarten Sie aber keine Größeneinsparungen dadurch; ziehen Sie stattdessen stets gzip/Brotli oberhalb des Base64-Textes in Betracht.
F: Kann ich ein JPEG in eine URL-sichere Base64-Nutzlast zur Verwendung in einer URL kodieren?
A: Ja — wechseln Sie zu unserem Base64url-Encoder (RFC 4648 §5), der das Alphabet -_ anstelle von +/ verwendet und das abschließende =-Padding weglässt. Das ergibt eine Nutzlast, die sicher in einen Query-String oder ein JWT eingefügt werden kann. Standard-Base64-JPEG-Nutzdaten sind meist Hunderte KB lang und sprengen viele URL-Längenbegrenzungen (2–8 KB je nach Browser/Server); auf eine Datei zu verlinken ist daher fast immer die bessere Idee, als das gesamte Foto in einer URL zu kodieren.
F: Welche JPG-Größe kann ich kodieren, bevor mein Browser den Speicher erschöpft?
A: Die Kodierung erfolgt mit FileReader streamend und dann wird btoa() auf das Ergebnis angewandt. Moderne Desktop-Browser verarbeiten 100–200 MB Eingaben problemlos; mobile Browser schaffen zuverlässig bis zu ~40 MB, bevor der Speicherdruck einsetzt. Für wirklich riesige Bilder (RAW-zu-JPEG-Exporte aus Mittelformatkameras) ziehen Sie einen serverseitigen Encoder oder Chunk-basierte Verarbeitung in Betracht — unser Tool warnt Sie, wenn Ihr Foto größer als 100 MB ist.
F: JPG → Base64 vs. PNG → Base64 — was sollte ich verwenden?
A: Verwenden Sie JPG → Base64 für Fotos, Camera-Rolls, Social-Media-Bilder und alles mit weichen Farbverläufen, bei denen 80–90 % JPEG-Qualität akzeptabel sind. Ein typisches 1080p-Foto ist ~200 KB als JPEG vs. ~2 MB als PNG. Verwenden Sie PNG → Base64 für Icons, Logos, Screenshots, Diagramme und alles mit Transparenz oder gestochen scharfen Kanten. Die Kombination: ein Base64-JPG für das Hero-Foto plus ein Base64-PNG für das scharfe Overlay-Icon ist ein gängiges Muster.